<div dir="ltr">Hi Rostislav,<br><br>Thank you for the patch and for reporting this.<br><br>The bug is real: an unvalidated data->block[0] in the native SMBus<br>path can cause OOB access, and your analysis is correct.<br><br>However, I'd prefer to fix this in the I2C core rather than in<br>individual drivers. Here is why:<br><br>drivers/i2c/i2c-core-smbus.c already validates block size in the<br>emulated path (i2c_smbus_xfer_emulated): for I2C_SMBUS_BLOCK_DATA<br>write, I2C_SMBUS_I2C_BLOCK_DATA, and I2C_SMBUS_BLOCK_PROC_CALL it<br>rejects data->block[0] > I2C_SMBUS_BLOCK_MAX with -EINVAL. But when<br>the adapter provides a native smbus_xfer, __i2c_smbus_xfer() calls<br>it without any prior validation on data->block[0].<br><br>This means every native SMBus adapter is exposed. For example,<br>hid-mcp2221 has the exact same class of bug -- it uses data->block[0]<br>in the block paths without any upper-bound check. hid-cp2112 happens<br>to have a driver-level guard, but relying on each driver to do this<br>independently is fragile.<br><br>Fixing it once in __i2c_smbus_xfer() protects all native SMBus<br>adapters and aligns the native path with the emulated path's contract.<br><br>Also note that the correct bound is data->block[0] > I2C_SMBUS_BLOCK_MAX<br>(i.e. > 32), consistent with the UAPI definition of union i2c_smbus_data<br>and the emulated path checks. The + 1 in the submitted patch would allow<br>33, which is already out of spec per the SMBus standard.<br><br>Could you please respin the patch against drivers/i2c/i2c-core-smbus.c<br>instead? Something like in the attached .diff file, added in __i2c_smbus_xfer() right<br>after flags &= ... and before xfer_func = adapter->algo->smbus_xfer<div><br>You can keep the same Reported-by, Closes, and Fixes tags. Once this<br>core patch is in, we won't need separate driver-level checks in<br>hid-ft260 (or hid-mcp2221).<br><br>Thanks,<br>Michael</div></div><br><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Fri, Feb 6, 2026 at 6:36 AM Rostislav Nesin <<a href="mailto:ssp.nesin@crpt.ru">ssp.nesin@crpt.ru</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">In ft260_smbus_xfer(), data->block[0] specifies the data length for<br>
block transfers. Without proper validation, a caller can set block[0]<br>
to a value larger than I2C_SMBUS_BLOCK_MAX (32), causing out-of-bounds<br>
access in both ft260_smbus_write() and ft260_i2c_read(). This<br>
triggered the out-of-bounds access reported by syzbot.<br>
<br>
BUG: KASAN: stack-out-of-bounds in ft260_smbus_write+0x19b/0x2f0 drivers/hid/hid-ft260.c:486<br>
Read of size 42 at addr ffffc90003427d81 by task syz.2.65/6119<br>
<br>
CPU: 0 UID: 0 PID: 6119 Comm: syz.2.65 Not tainted syzkaller #0 PREEMPT(full) <br>
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/25/2025<br>
Call Trace:<br>
<TASK><br>
__dump_stack lib/dump_stack.c:94 [inline]<br>
dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:120<br>
print_address_description mm/kasan/report.c:378 [inline]<br>
print_report+0xcd/0x630 mm/kasan/report.c:482<br>
kasan_report+0xe0/0x110 mm/kasan/report.c:595<br>
check_region_inline mm/kasan/generic.c:194 [inline]<br>
kasan_check_range+0x100/0x1b0 mm/kasan/generic.c:200<br>
__asan_memcpy+0x23/0x60 mm/kasan/shadow.c:105<br>
ft260_smbus_write+0x19b/0x2f0 drivers/hid/hid-ft260.c:486<br>
ft260_smbus_xfer+0x22c/0x640 drivers/hid/hid-ft260.c:736<br>
__i2c_smbus_xfer drivers/i2c/i2c-core-smbus.c:591 [inline]<br>
__i2c_smbus_xfer+0x4f0/0xf60 drivers/i2c/i2c-core-smbus.c:554<br>
i2c_smbus_xfer drivers/i2c/i2c-core-smbus.c:546 [inline]<br>
i2c_smbus_xfer+0x200/0x3c0 drivers/i2c/i2c-core-smbus.c:536<br>
i2cdev_ioctl_smbus+0x237/0x990 drivers/i2c/i2c-dev.c:389<br>
i2cdev_ioctl+0x361/0x840 drivers/i2c/i2c-dev.c:478<br>
vfs_ioctl fs/ioctl.c:51 [inline]<br>
__do_sys_ioctl fs/ioctl.c:597 [inline]<br>
__se_sys_ioctl fs/ioctl.c:583 [inline]<br>
__x64_sys_ioctl+0x18e/0x210 fs/ioctl.c:583<br>
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]<br>
do_syscall_64+0xcd/0xf80 arch/x86/entry/syscall_64.c:94<br>
entry_SYSCALL_64_after_hwframe+0x77/0x7f<br>
</TASK><br>
<br>
Add validation for data->block[0] > I2C_SMBUS_BLOCK_MAX + 1 at the<br>
start of I2C_SMBUS_BLOCK_DATA and I2C_SMBUS_I2C_BLOCK_DATA cases to<br>
protect both read and write paths.<br>
<br>
Found by Linux Verification Center (<a href="http://linuxtesting.org" rel="noreferrer" target="_blank">linuxtesting.org</a>) with Syzkaller.<br>
<br>
Reported-by: <a href="mailto:syzbot%2B64ca69977b37604cd6d9@syzkaller.appspotmail.com" target="_blank">syzbot+64ca69977b37604cd6d9@syzkaller.appspotmail.com</a><br>
Closes: <a href="https://syzkaller.appspot.com/bug?extid=64ca69977b37604cd6d9" rel="noreferrer" target="_blank">https://syzkaller.appspot.com/bug?extid=64ca69977b37604cd6d9</a><br>
Fixes: 6a82582d9fa4 ("HID: ft260: add usb hid to i2c host bridge driver")<br>
Signed-off-by: Rostislav Nesin <<a href="mailto:ssp.nesin@crpt.ru" target="_blank">ssp.nesin@crpt.ru</a>><br>
---<br>
drivers/hid/hid-ft260.c | 8 ++++++++<br>
1 file changed, 8 insertions(+)<br>
<br>
diff --git a/drivers/hid/hid-ft260.c b/drivers/hid/hid-ft260.c<br>
index 79505c64dbfe..7bd858e40826 100644<br>
--- a/drivers/hid/hid-ft260.c<br>
+++ b/drivers/hid/hid-ft260.c<br>
@@ -659,6 +659,10 @@ static int ft260_smbus_xfer(struct i2c_adapter *adapter, u16 addr, u16 flags,<br>
}<br>
break;<br>
case I2C_SMBUS_BLOCK_DATA:<br>
+ if (data->block[0] > I2C_SMBUS_BLOCK_MAX + 1) {<br>
+ ret = -EINVAL;<br>
+ goto smbus_exit;<br>
+ }<br>
if (read_write == I2C_SMBUS_READ) {<br>
ret = ft260_smbus_write(dev, addr, cmd, NULL, 0,<br>
FT260_FLAG_START);<br>
@@ -675,6 +679,10 @@ static int ft260_smbus_xfer(struct i2c_adapter *adapter, u16 addr, u16 flags,<br>
}<br>
break;<br>
case I2C_SMBUS_I2C_BLOCK_DATA:<br>
+ if (data->block[0] > I2C_SMBUS_BLOCK_MAX + 1) {<br>
+ ret = -EINVAL;<br>
+ goto smbus_exit;<br>
+ }<br>
if (read_write == I2C_SMBUS_READ) {<br>
ret = ft260_smbus_write(dev, addr, cmd, NULL, 0,<br>
FT260_FLAG_START);<br>
-- <br>
2.34.1<br>
</blockquote></div>