Linux Kernel up to 7.0.13 i2c-stub drivers/i2c/i2c-stub.c stub_xfer block out-of-bounds

Summaryinfo

A vulnerability, which was classified as very critical, has been found in Linux Kernel up to 7.0.13. This impacts the function stub_xfer of the file drivers/i2c/i2c-stub.c of the component i2c-stub. The manipulation of the argument block leads to out-of-bounds. This vulnerability is referenced as CVE-2026-64191. The attack can only be performed from a local environment. No exploit is available.

Detailsinfo

A vulnerability, which was classified as very critical, has been found in Linux Kernel up to 7.0.13. This issue affects the function stub_xfer of the file drivers/i2c/i2c-stub.c of the component i2c-stub. The manipulation of the argument block with an unknown input leads to a out-of-bounds vulnerability. Using CWE to declare the problem leads to CWE-125. The product reads data past the end, or before the beginning, of the intended buffer. Impacted is confidentiality, integrity, and availability. The summary by CVE is:

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().

It is possible to read the advisory at git.kernel.org. The identification of this vulnerability is CVE-2026-64191 since 07/19/2026. The exploitation is known to be easy. Attacking locally is a requirement. Technical details of the vulnerability are known, but there is no available exploit. The pricing for an exploit might be around USD $0-$5k at the moment (estimation calculated on 07/20/2026).

Upgrading to version 5.10.260, 5.15.211, 6.1.177, 6.6.144, 6.12.95, 6.18.37 or 7.0.14 eliminates this vulnerability.

Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.

Productinfo

Type

• Operating System

Vendor

• Linux

Name

• Kernel

Version

• 5.10.259
• 5.15.210
• 6.1.176
• 6.6.143
• 6.12.0
• 6.12.1
• 6.12.2
• 6.12.3
• 6.12.4
• 6.12.5
• 6.12.6
• 6.12.7
• 6.12.8
• 6.12.9
• 6.12.10
• 6.12.11
• 6.12.12
• 6.12.13
• 6.12.14
• 6.12.15
• 6.12.16
• 6.12.17
• 6.12.18
• 6.12.19
• 6.12.20
• 6.12.21
• 6.12.22
• 6.12.23
• 6.12.24
• 6.12.25
• 6.12.26
• 6.12.27
• 6.12.28
• 6.12.29
• 6.12.30
• 6.12.31
• 6.12.32
• 6.12.33
• 6.12.34
• 6.12.35
• 6.12.36
• 6.12.37
• 6.12.38
• 6.12.39
• 6.12.40
• 6.12.41
• 6.12.42
• 6.12.43
• 6.12.44
• 6.12.45
• 6.12.46
• 6.12.47
• 6.12.48
• 6.12.49
• 6.12.50
• 6.12.51
• 6.12.52
• 6.12.53
• 6.12.54
• 6.12.55
• 6.12.56
• 6.12.57
• 6.12.58
• 6.12.59
• 6.12.60
• 6.12.61
• 6.12.62
• 6.12.63
• 6.12.64
• 6.12.65
• 6.12.66
• 6.12.67
• 6.12.68
• 6.12.69
• 6.12.70
• 6.12.71
• 6.12.72
• 6.12.73
• 6.12.74
• 6.12.75
• 6.12.76
• 6.12.77
• 6.12.78
• 6.12.79
• 6.12.80
• 6.12.81
• 6.12.82
• 6.12.83
• 6.12.84
• 6.12.85
• 6.12.86
• 6.12.87
• 6.12.88
• 6.12.89
• 6.12.90
• 6.12.91
• 6.12.92
• 6.12.93
• 6.12.94
• 6.18.0
• 6.18.1
• 6.18.2
• 6.18.3
• 6.18.4
• 6.18.5
• 6.18.6
• 6.18.7
• 6.18.8
• 6.18.9
• 6.18.10
• 6.18.11
• 6.18.12
• 6.18.13
• 6.18.14
• 6.18.15
• 6.18.16
• 6.18.17
• 6.18.18
• 6.18.19
• 6.18.20
• 6.18.21
• 6.18.22
• 6.18.23
• 6.18.24
• 6.18.25
• 6.18.26
• 6.18.27
• 6.18.28
• 6.18.29
• 6.18.30
• 6.18.31
• 6.18.32
• 6.18.33
• 6.18.34
• 6.18.35
• 6.18.36
• 7.0.0
• 7.0.1
• 7.0.2
• 7.0.3
• 7.0.4
• 7.0.5
• 7.0.6
• 7.0.7
• 7.0.8
• 7.0.9
• 7.0.10
• 7.0.11
• 7.0.12
• 7.0.13

License

• open-source

Website

• Vendor: https://www.kernel.org/

CPE 2.3info

• 🔒
• 🔒
• 🔒

CPE 2.2info

• 🔒
• 🔒
• 🔒

CVSSv4info

CVSSv3info

CVSSv2info

Exploitinginfo

Threat Intelligenceinfo

Countermeasuresinfo

Timelineinfo

Sourcesinfo

Entryinfo

Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.

Discussion