{"id":82299,"date":"2026-07-20T20:48:22","date_gmt":"2026-07-20T17:18:22","guid":{"rendered":"https:\/\/afaghhosting.net\/blog\/cve-2026-64191-i2c-stub-reject-i2c-block-transfers-with-invalid-length\/"},"modified":"2026-07-20T20:48:22","modified_gmt":"2026-07-20T17:18:22","slug":"cve-2026-64191-i2c-stub-reject-i2c-block-transfers-with-invalid-length","status":"publish","type":"post","link":"https:\/\/afaghhosting.net\/blog\/cve-2026-64191-i2c-stub-reject-i2c-block-transfers-with-invalid-length\/","title":{"rendered":"CVE-2026-64191 &#8211; i2c: stub: Reject I2C block transfers with invalid length"},"content":{"rendered":"<p>CVE ID :CVE-2026-64191<\/p>\n<p>  Published : July 20, 2026, 5:18 p.m. | 25\u00a0minutes ago<\/p>\n<p>  Description :In the Linux kernel, the following vulnerability has been resolved:<\/p>\n<p>i2c: stub: Reject I2C block transfers with invalid length<\/p>\n<p>The I2C_SMBUS_I2C_BLOCK_DATA case in stub_xfer() uses data-&gt;block[0]\nas the transfer length. The existing check only clamps it to avoid<br \/>\noverrunning the chip-&gt;words[256] register array, but does not validate<br \/>\nit against I2C_SMBUS_BLOCK_MAX (32), which is the limit of the union<br \/>\ni2c_smbus_data.block buffer (34 bytes total). The driver is a<br \/>\ndevelopment\/test tool (CONFIG_I2C_STUB=m, not built by default)<br \/>\nthat must be loaded with a chip_addr= parameter.<\/p>\n<p>A local user with access to \/dev\/i2c-* can issue an I2C_SMBUS ioctl<br \/>\nwith I2C_SMBUS_I2C_BLOCK_DATA and data-&gt;block[0] &gt; 32, causing<br \/>\nstub_xfer() to read or write past the end of the union<br \/>\ni2c_smbus_data.block buffer:<\/p>\n<p> BUG: KASAN: stack-out-of-bounds in stub_xfer (drivers\/i2c\/i2c-stub.c:223)<br \/>\n Read of size 1 at addr ffff88800abcfd92 by task exploit\/81<br \/>\n Call Trace:<\/p>\n<p>  stub_xfer (drivers\/i2c\/i2c-stub.c:223)<br \/>\n  __i2c_smbus_xfer (drivers\/i2c\/i2c-core-smbus.c:593)<br \/>\n  i2c_smbus_xfer (drivers\/i2c\/i2c-core-smbus.c:536)<br \/>\n  i2cdev_ioctl_smbus (drivers\/i2c\/i2c-dev.c:391)<br \/>\n  i2cdev_ioctl (drivers\/i2c\/i2c-dev.c:478)<br \/>\n  __x64_sys_ioctl (fs\/ioctl.c:583)<br \/>\n  do_syscall_64 (arch\/x86\/entry\/syscall_64.c:94)<br \/>\n  entry_SYSCALL_64_after_hwframe (arch\/x86\/entry\/entry_64.S:130)<\/p>\n<p>The bug exists because i2c-stub implements .smbus_xfer directly,<br \/>\nbypassing the I2C_SMBUS_BLOCK_MAX validation in<br \/>\ni2c_smbus_xfer_emulated(). The I2C_SMBUS_BLOCK_DATA case in the same<br \/>\nfunction correctly validates against I2C_SMBUS_BLOCK_MAX, but the<br \/>\nI2C_SMBUS_I2C_BLOCK_DATA case does not.<\/p>\n<p>Fix by rejecting transfers with data-&gt;block[0] == 0 or<br \/>\ndata-&gt;block[0] &gt; I2C_SMBUS_BLOCK_MAX with -EINVAL, consistent with<br \/>\nboth the I2C_SMBUS_BLOCK_DATA case in the same function and the<br \/>\nI2C_SMBUS_I2C_BLOCK_DATA validation in i2c_smbus_xfer_emulated().<\/p>\n<p>  Severity: 0.0 | NA<\/p>\n<p>  Visit the link for more details, such as CVSS details, affected products, timeline, and more&#8230;\u00a0<\/p>\n","protected":false},"excerpt":{"rendered":"<p>CVE ID :CVE-2026-64191 Published : July 20, 2026, 5:18 p.m. | 25\u00a0minutes ago Description :In the Linux kernel, the following vulnerability has been resolved: i2c: stub: Reject I2C block transfers with invalid length The I2C_SMBUS_I2C_BLOCK_DATA case in stub_xfer() uses data-&gt;block[0] as the transfer length. The existing check only clamps it to avoid overrunning the chip-&gt;words[256] &hellip;<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[26],"tags":[],"class_list":["post-82299","post","type-post","status-publish","format-standard","hentry","category-vulnerability"],"_links":{"self":[{"href":"https:\/\/afaghhosting.net\/blog\/wp-json\/wp\/v2\/posts\/82299","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/afaghhosting.net\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/afaghhosting.net\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/afaghhosting.net\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/afaghhosting.net\/blog\/wp-json\/wp\/v2\/comments?post=82299"}],"version-history":[{"count":0,"href":"https:\/\/afaghhosting.net\/blog\/wp-json\/wp\/v2\/posts\/82299\/revisions"}],"wp:attachment":[{"href":"https:\/\/afaghhosting.net\/blog\/wp-json\/wp\/v2\/media?parent=82299"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/afaghhosting.net\/blog\/wp-json\/wp\/v2\/categories?post=82299"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/afaghhosting.net\/blog\/wp-json\/wp\/v2\/tags?post=82299"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}