CVE-2026-64191 in Linux
Summary
by MITRE • 07/20/2026
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->block[0]
as the transfer length. The existing check only clamps it to avoid overrunning the chip->words[256] register array, but does not validate
it against I2C_SMBUS_BLOCK_MAX (32), which is the limit of the union i2c_smbus_data.block buffer (34 bytes total). The driver is a development/test tool (CONFIG_I2C_STUB=m, not built by default) that must be loaded with a chip_addr= parameter.
A local user with access to /dev/i2c-* can issue an I2C_SMBUS ioctl with I2C_SMBUS_I2C_BLOCK_DATA and data->block[0] > 32, causing
stub_xfer() to read or write past the end of the union i2c_smbus_data.block buffer:
BUG: KASAN: stack-out-of-bounds in stub_xfer (drivers/i2c/i2c-stub.c:223) Read of size 1 at addr ffff88800abcfd92 by task exploit/81 Call Trace: <TASK> stub_xfer (drivers/i2c/i2c-stub.c:223) __i2c_smbus_xfer (drivers/i2c/i2c-core-smbus.c:593) i2c_smbus_xfer (drivers/i2c/i2c-core-smbus.c:536) i2cdev_ioctl_smbus (drivers/i2c/i2c-dev.c:391) i2cdev_ioctl (drivers/i2c/i2c-dev.c:478) __x64_sys_ioctl (fs/ioctl.c:583) do_syscall_64 (arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) </TASK>
The bug exists because i2c-stub implements .smbus_xfer directly, bypassing the I2C_SMBUS_BLOCK_MAX validation in i2c_smbus_xfer_emulated(). The I2C_SMBUS_BLOCK_DATA case in the same function correctly validates against I2C_SMBUS_BLOCK_MAX, but the I2C_SMBUS_I2C_BLOCK_DATA case does not.
Fix by rejecting transfers with data->block[0] == 0 or
data->block[0] > I2C_SMBUS_BLOCK_MAX with -EINVAL, consistent with
both the I2C_SMBUS_BLOCK_DATA case in the same function and the I2C_SMBUS_I2C_BLOCK_DATA validation in i2c_smbus_xfer_emulated().
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 07/20/2026
The vulnerability resides within the Linux kernel's I2C stub driver implementation, specifically in the stub_xfer() function where improper validation of I2C block transfer lengths leads to potential memory corruption. This issue affects the i2c-stub driver which serves as a development and testing tool that must be explicitly loaded with a chip_addr parameter. The flaw manifests when processing I2C_SMBUS_I2C_BLOCK_DATA ioctl commands where the driver incorrectly uses data->block[0] as the transfer length without proper bounds checking against the standard I2C_SMBUS_BLOCK_MAX limit of 32 bytes.
The technical implementation error stems from the driver's direct implementation of the .smbus_xfer method which bypasses the standard validation mechanisms present in i2c_smbus_xfer_emulated(). While other cases within the same function properly validate against I2C_SMBUS_BLOCK_MAX, the I2C_SMBUS_I2C_BLOCK_DATA case fails to perform this critical check. This oversight allows malicious local users with access to /dev/i2c-* devices to craft ioctl requests with block lengths exceeding the buffer capacity, leading to stack-based out-of-bounds memory accesses as demonstrated by the KASAN stack trace showing a read operation of size 1 at address ffff88800abcfd92.
The operational impact of this vulnerability extends beyond simple memory corruption, potentially enabling privilege escalation or system instability when exploited by local attackers. The vulnerability exists in the kernel's device driver layer and specifically affects systems where the i2c-stub module is loaded, making it particularly concerning for development environments or testing scenarios where such modules might be enabled. This flaw represents a direct violation of proper input validation principles and can lead to unpredictable behavior including kernel crashes or data corruption that could compromise system integrity.
The fix implements a straightforward but critical validation mechanism that rejects transfers with data->block[0] equal to zero or exceeding I2C_SMBUS_BLOCK_MAX by returning -EINVAL error codes. This approach aligns the stub driver behavior with both the existing validation patterns within the same function and the standard validation logic present in i2c_smbus_xfer_emulated(). The solution addresses the core issue by ensuring that all block transfer operations respect the defined buffer boundaries, thereby preventing the stack-out-of-bounds condition that could lead to memory corruption or exploitation. This remediation follows established security practices for input validation and aligns with common security frameworks such as those addressing CWE-129 Input Validation and CWE-787 Out-of-bounds Write vulnerabilities, while also mitigating potential attack vectors classified under the ATT&CK technique of privilege escalation through kernel exploits.