CVE-2026-64191: 
Linux Kernel vulnerability analysis and mitigation

CVE-2026-64191 is a stack out-of-bounds read/write vulnerability in the Linux kernel's i2c-stub driver (drivers/i2c/i2c-stub.c), caused by insufficient validation of the transfer length in I2C_SMBUS_I2C_BLOCK_DATA transactions. A local user with access to /dev/i2c-* devices can trigger the bug by issuing a crafted I2C_SMBUS ioctl with a block length exceeding 32 bytes, causing the kernel to read or write past the end of the union i2c_smbus_data.block buffer. The vulnerability was published on July 20, 2026, and affects the Linux kernel from version 2.6.33 onward; fixed versions include 5.10.260, 5.15.211, 6.1.177, 6.6.144, 6.12.95, 6.18.37, 7.0.14, and 7.1+. The CVSS category is estimated as Medium (GitHub Advisory, Feedly).

The root cause is improper input validation (CWE class: out-of-bounds read/write) in the stub_xfer() function within drivers/i2c/i2c-stub.c. The I2C_SMBUS_I2C_BLOCK_DATA case uses data->block[0] as the transfer length and only clamps it to prevent overrunning the chip->words[256] register array, but does not enforce the I2C_SMBUS_BLOCK_MAX limit of 32 bytes — the actual boundary of the union i2c_smbus_data.block buffer (34 bytes total). Because i2c-stub implements .smbus_xfer directly, it bypasses the I2C_SMBUS_BLOCK_MAX validation present in i2c_smbus_xfer_emulated(), which correctly validates the I2C_SMBUS_BLOCK_DATA case. Exploitation requires the i2c-stub kernel module to be loaded (it is not built by default; CONFIG_I2C_STUB=m) with a chip_addr= parameter, and the attacker must have read/write access to a /dev/i2c-* device node (GitHub Advisory).

Successful exploitation can result in kernel stack out-of-bounds memory access, leading to information disclosure (reading sensitive kernel stack data) or a kernel crash (denial of service). Because the affected driver is a development/test stub not loaded in production by default, the practical impact is limited to systems where i2c-stub has been explicitly loaded. Privilege escalation to kernel-level code execution is theoretically possible depending on what data is overwritten, but no such scenario has been publicly demonstrated (GitHub Advisory, Feedly).

1. Precondition check: Confirm the target system has the i2c-stub kernel module loaded (lsmod | grep i2c_stub) with a chip_addr= parameter, and that the attacker has read/write access to a /dev/i2c-* device node.
2. Open the I2C device: Open the relevant /dev/i2c-N device file corresponding to the stub adapter (e.g., fd = open("/dev/i2c-0", O_RDWR)).
3. Craft the malicious ioctl: Construct an i2c_smbus_ioctl_data structure with read_write, command, size = I2C_SMBUS_I2C_BLOCK_DATA, and set data->block[0] to a value greater than 32 (e.g., 33–255) to exceed the I2C_SMBUS_BLOCK_MAX boundary.
4. Issue the ioctl: Call ioctl(fd, I2C_SMBUS, &args) to trigger stub_xfer(), causing it to read or write past the end of the union i2c_smbus_data.block buffer on the kernel stack.
5. Observe the result: Depending on kernel configuration and what lies beyond the buffer, the outcome may be a KASAN-detected stack-out-of-bounds report, kernel crash, or disclosure of adjacent stack memory (GitHub Advisory).

• Logs: Kernel log (dmesg) entries containing BUG: KASAN: stack-out-of-bounds in stub_xfer or similar KASAN reports referencing drivers/i2c/i2c-stub.c:223.
• Logs: Call stack traces in kernel logs showing stub_xfer → __i2c_smbus_xfer → i2c_smbus_xfer → i2cdev_ioctl_smbus → i2cdev_ioctl → __x64_sys_ioctl.
• Process: Unexpected processes (e.g., named exploit) issuing ioctl syscalls against /dev/i2c-* devices, particularly from non-privileged or unexpected user accounts.
• File System: Presence of the i2c-stub module on production systems where it is not expected (/sys/module/i2c_stub/ or lsmod output).

Apply the upstream kernel patches available for the following stable branches: 5.10.260, 5.15.211, 6.1.177, 6.6.144, 6.12.95, 6.18.37, 7.0.14, and 7.1+. The fix rejects I2C_SMBUS_I2C_BLOCK_DATA transfers where data->block[0] == 0 or data->block[0] > I2C_SMBUS_BLOCK_MAX with -EINVAL. As a workaround on systems where the i2c-stub module is not required, unload it (rmmod i2c_stub) and blacklist it to prevent automatic loading. Additionally, restrict access to /dev/i2c-* device nodes to only trusted users or processes (GitHub Advisory).