In the Linux kernel, the following vulnerability has been resolved:<\/p>\n
i2c: smbus: reject oversized block transfers in the common path<\/p>\n
The SMBus block transfer length data->block[0] is validated in
\ni2c_smbus_xfer_emulated() but that check runs too late for tracepoints
\nand is skipped entirely when the adapter provides a native smbus_xfer
\nimplementation. This allows user-controlled oversized block lengths to
\nreach tracepoint memcpy calls and driver callbacks unchecked.<\/p>\n
Add an early validation in __i2c_smbus_xfer() that rejects block
\ntransfers whose caller-supplied length is zero or exceeds
\nI2C_SMBUS_BLOCK_MAX before any tracepoint fires or driver callback
\nruns. data->block[0] is filled in by the device on SMBus block reads,
\nso the check is scoped to operations where the length is actually
\nsupplied by the caller. This is consistent with the existing -EINVAL
\nconvention in the emulated path and protects all downstream consumers
\nat once: the smbus_write tracepoint, all native smbus_xfer driver
\nimplementations, and the emulated path.<\/p>\n
Two distinct bugs are fixed by this change:<\/p>\n
Bug 1: smbus_write tracepoint OOB (include\/trace\/events\/smbus.h)
\n trace_smbus_write() fires before any validation and copies
\n data->block[0]+1 bytes into a 34-byte event buffer. With
\n block[0]=0xfe the tracepoint copies 255 bytes, overflowing by 221.<\/p>\n
BUG: KASAN: stack-out-of-bounds in trace_event_raw_event_smbus_write+0x27c\/0x530
\n Read of size 255 at addr ffff88800d98fcf8 by task poc_smbus\/91
\n Call Trace:<\/p>\n
__asan_memcpy+0x23\/0x80
\n trace_event_raw_event_smbus_write+0x27c\/0x530
\n __i2c_smbus_xfer+0x43a\/0xa40
\n i2c_smbus_xfer+0x19e\/0x340
\n i2cdev_ioctl_smbus+0x38f\/0x7f0
\n i2cdev_ioctl+0x35e\/0x680
\n __x64_sys_ioctl+0x147\/0x1e0
\n do_syscall_64+0xcf\/0x15a0
\n entry_SYSCALL_64_after_hwframe+0x76\/0x7e<\/p>\n
Bug 2: i2c-stub I2C_SMBUS_I2C_BLOCK_DATA OOB (drivers\/i2c\/i2c-stub.c)
\n stub_xfer() implements .smbus_xfer directly and only clamps
\n block[0] against 256-command, not I2C_SMBUS_BLOCK_MAX. With
\n block[0]=0xff and command=0 the loop accesses block[1+i] for
\n i up to 254, far past the 34-byte union.<\/p>\n
UBSAN: array-index-out-of-bounds in drivers\/i2c\/i2c-stub.c:223:44
\n index 34 is out of range for type ‘__u8 [34]’
\n Call Trace:<\/p>\n
__ubsan_handle_out_of_bounds+0xd7\/0x120
\n stub_xfer+0x1971\/0x198f [i2c_stub]
\n __i2c_smbus_xfer+0x306\/0xa40
\n i2c_smbus_xfer+0x19e\/0x340
\n i2cdev_ioctl_smbus+0x38f\/0x7f0
\n i2cdev_ioctl+0x35e\/0x680
\n __x64_sys_ioctl+0x147\/0x1e0
\n do_syscall_64+0xcf\/0x15a0
\n entry_SYSCALL_64_after_hwframe+0x76\/0x7e<\/p>\n
Both traces reproduced on v7.0-rc6+i2c\/for-current with KASAN+UBSAN.<\/p>\n","protected":false},"excerpt":{"rendered":"
In the Linux kernel, the following vulnerability has been resolved:<\/p>\n
i2c: smbus: reject oversized block transfers in the common path<\/p>\n
The SMBus block transfer length data->block[0] is validated in
\ni2c<\/p>\n","protected":false},"template":"","meta":[],"categories":[],"tags":[],"class_list":["post-28590","vuln","type-vuln","status-publish","hentry"],"_links":{"self":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=\/wp\/v2\/vuln\/28590","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=\/wp\/v2\/vuln"}],"about":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=\/wp\/v2\/types\/vuln"}],"wp:attachment":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=28590"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=28590"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=28590"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}