CVE-2026-64191

In the Linux kernel, the following vulnerability has been resolved:

i2c: stub: Reject I2C block transfers with invalid length

The I2CSMBUSI2CBLOCKDATA case in stubxfer() 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 I2CSMBUSBLOCKMAX (32), which is the limit of the union i2csmbusdata.block buffer (34 bytes total). The driver is a development/test tool (CONFIGI2CSTUB=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 I2CSMBUS ioctl with I2CSMBUSI2CBLOCKDATA and data->block[0] > 32, causing stubxfer() to read or write past the end of the union i2csmbusdata.block buffer:

BUG: KASAN: stack-out-of-bounds in stubxfer (drivers/i2c/i2c-stub.c:223) Read of size 1 at addr ffff88800abcfd92 by task exploit/81 Call Trace: <TASK> stubxfer (drivers/i2c/i2c-stub.c:223) __i2csmbusxfer (drivers/i2c/i2c-core-smbus.c:593) i2c_smbusxfer (drivers/i2c/i2c-core-smbus.c:536) i2cdevioctlsmbus (drivers/i2c/i2c-dev.c:391) i2cdevioctl (drivers/i2c/i2c-dev.c:478) __x64sysioctl (fs/ioctl.c:583) dosyscall64 (arch/x86/entry/syscall64.c:94) entrySYSCALL64afterhwframe (arch/x86/entry/entry64.S:130) </TASK>

The bug exists because i2c-stub implements .smbusxfer directly, bypassing the I2CSMBUSBLOCKMAX validation in i2csmbusxferemulated(). The I2CSMBUSBLOCKDATA case in the same function correctly validates against I2CSMBUSBLOCKMAX, but the I2CSMBUSI2CBLOCK_DATA case does not.

Fix by rejecting transfers with data->block[0] == 0 or data->block[0] > I2CSMBUSBLOCKMAX with -EINVAL, consistent with both the I2CSMBUSBLOCKDATA case in the same function and the I2CSMBUSI2CBLOCKDATA validation in i2csmbusxfer_emulated().