CVE-2026-64191 Overview
CVE-2026-64191 is an out-of-bounds read/write vulnerability in the Linux kernel i2c-stub driver. The flaw exists in the stub_xfer() function within drivers/i2c/i2c-stub.c, where the I2C_SMBUS_I2C_BLOCK_DATA case fails to validate the transfer length against I2C_SMBUS_BLOCK_MAX (32 bytes). A local user with access to /dev/i2c-* can issue an I2C_SMBUS ioctl with data->block[0] > 32, causing the driver to read or write past the end of the union i2c_smbus_data.block buffer. The i2c-stub module is a development and test tool (CONFIG_I2C_STUB=m) that is not built by default and requires an explicit chip_addr= parameter to load.
Critical Impact
Local users with /dev/i2c-* access can trigger a stack out-of-bounds read/write, potentially leading to kernel memory corruption or information disclosure on systems where the i2c-stub module is loaded.
Affected Products
- Linux kernel builds with CONFIG_I2C_STUB=m enabled and the module loaded
- Development and test environments using the i2c-stub driver
- Distributions shipping the vulnerable drivers/i2c/i2c-stub.c implementation prior to the fix
Discovery Timeline
- 2026-07-20 - CVE-2026-64191 published to NVD
- 2026-07-20 - Last updated in NVD database
Technical Details for CVE-2026-64191
Vulnerability Analysis
The i2c-stub driver implements its own .smbus_xfer callback, bypassing the standard I2C_SMBUS_BLOCK_MAX validation performed in i2c_smbus_xfer_emulated(). Inside stub_xfer(), the I2C_SMBUS_I2C_BLOCK_DATA case uses data->block[0] as the transfer length. The pre-patch code only clamped this value to prevent overrun of the internal chip->words[256] register array. It did not check the value against the actual size of the caller-supplied union i2c_smbus_data.block buffer, which is only 34 bytes total with I2C_SMBUS_BLOCK_MAX defined as 32.
When a local user submits a crafted I2C_SMBUS ioctl with data->block[0] greater than 32, stub_xfer() iterates beyond the union buffer. KASAN confirms the out-of-bounds access: BUG: KASAN: stack-out-of-bounds in stub_xfer (drivers/i2c/i2c-stub.c:223). The call chain traverses i2cdev_ioctl → i2c_smbus_xfer → __i2c_smbus_xfer → stub_xfer, reading or writing memory adjacent to the stack-allocated i2c_smbus_data structure.
Root Cause
The root cause is missing input validation [CWE-125 / CWE-787] in the I2C_SMBUS_I2C_BLOCK_DATA handler. The sibling I2C_SMBUS_BLOCK_DATA case in the same function correctly validates against I2C_SMBUS_BLOCK_MAX, but the I2C_SMBUS_I2C_BLOCK_DATA branch inherited only the register-array bounds check. Because i2c-stub supplies its own transfer callback, the generic emulation layer's protective validation never executes.
Attack Vector
Exploitation requires local access to an /dev/i2c-* device node on a host where the i2c-stub module is loaded with a valid chip_addr= parameter. The attacker opens the device, then issues an I2C_SMBUS ioctl specifying I2C_SMBUS_I2C_BLOCK_DATA with data->block[0] set above 32. The driver then performs an out-of-bounds read or write on the stack buffer during transfer processing. Because access to /dev/i2c-* is typically restricted to root or the i2c group, and because the module is disabled by default, the practical attack surface is limited to systems where administrators have deliberately enabled the test driver.
No public exploit code is available for this issue. See the kernel commit references for the patched validation logic.
Detection Methods for CVE-2026-64191
Indicators of Compromise
- KASAN reports containing stack-out-of-bounds in stub_xfer in kernel logs (dmesg, /var/log/kern.log)
- Unexpected kernel oops or panic traces referencing stub_xfer, __i2c_smbus_xfer, or i2cdev_ioctl_smbus
- Presence of the i2c_stub module on production systems where it should not be loaded, visible via lsmod | grep i2c_stub
Detection Strategies
- Audit loaded kernel modules across the fleet and flag any host where i2c_stub appears outside approved development environments
- Monitor ioctl syscall telemetry against /dev/i2c-* device nodes from non-root or unexpected user contexts
- Enable KASAN on test kernels to surface out-of-bounds accesses during pre-production validation
Monitoring Recommendations
- Forward kernel ring buffer logs to a central SIEM and alert on KASAN and stub_xfer strings
- Track filesystem access events on /dev/i2c-* device nodes to identify unauthorized users interacting with I2C interfaces
- Include i2c_stub in module-load allowlist policies enforced by tools such as kmod signing or lockdown mode
How to Mitigate CVE-2026-64191
Immediate Actions Required
- Unload the i2c_stub module on any system where it is not actively required using modprobe -r i2c_stub
- Restrict access to /dev/i2c-* device nodes to the minimum set of trusted administrators
- Apply the upstream Linux kernel patch that adds the I2C_SMBUS_BLOCK_MAX validation to stub_xfer()
- Blacklist the i2c_stub module on production hosts to prevent accidental loading
Patch Information
The fix rejects transfers with data->block[0] == 0 or data->block[0] > I2C_SMBUS_BLOCK_MAX by returning -EINVAL, aligning the I2C_SMBUS_I2C_BLOCK_DATA case with the existing I2C_SMBUS_BLOCK_DATA validation and with i2c_smbus_xfer_emulated(). Patched commits are available in the stable kernel trees, including commit 7e9072dbd5f2, commit 0526931b16e5, commit 1c4ffe6b4f04, commit 21e87f336ac6, commit 3fd225f3e4cd, commit 4bd8635f28c1, commit 5f4d2bd028eb, and commit 6036b5067a81. Rebuild affected distribution kernels or update to the vendor-shipped stable release that incorporates these commits.
Workarounds
- Rebuild the kernel without CONFIG_I2C_STUB where the driver is not needed
- Add blacklist i2c_stub to /etc/modprobe.d/ to prevent runtime loading
- Tighten udev rules and group ownership on /dev/i2c-* to limit local user access
# Configuration example
# Prevent i2c_stub from being loaded on production hosts
echo 'blacklist i2c_stub' | sudo tee /etc/modprobe.d/disable-i2c-stub.conf
echo 'install i2c_stub /bin/false' | sudo tee -a /etc/modprobe.d/disable-i2c-stub.conf
# Unload the module if currently loaded
sudo modprobe -r i2c_stub
# Restrict access to I2C device nodes
sudo chown root:root /dev/i2c-*
sudo chmod 0600 /dev/i2c-*
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

