PT-2026-104884 · Azure Linux · Kernel

Published

2026-09-24

·

Updated

2026-09-24

None

No severity ratings or metrics are available. When they are, we'll update the corresponding info on the page.
In the Linux kernel, the following vulnerability has been resolved:
i2c: smbus: reject oversized block transfers in the common path
The SMBus block transfer length data->block[0] is validated in i2c smbus xfer emulated() but that check runs too late for tracepoints and is skipped entirely when the adapter provides a native smbus xfer implementation. This allows user-controlled oversized block lengths to reach tracepoint memcpy calls and driver callbacks unchecked.
Add an early validation in i2c smbus xfer() that rejects block transfers whose caller-supplied length is zero or exceeds I2C SMBUS BLOCK MAX before any tracepoint fires or driver callback runs. data->block[0] is filled in by the device on SMBus block reads, so the check is scoped to operations where the length is actually supplied by the caller. This is consistent with the existing -EINVAL convention in the emulated path and protects all downstream consumers at once: the smbus write tracepoint, all native smbus xfer driver implementations, and the emulated path.
Two distinct bugs are fixed by this change:
Bug 1: smbus write tracepoint OOB (include/trace/events/smbus.h) trace smbus write() fires before any validation and copies data->block[0]+1 bytes into a 34-byte event buffer. With block[0]=0xfe the tracepoint copies 255 bytes, overflowing by 221.
BUG: KASAN: stack-out-of-bounds in trace event raw event smbus write+0x27c/0x530 Read of size 255 at addr ffff88800d98fcf8 by task poc smbus/91 Call Trace: asan memcpy+0x23/0x80 trace event raw event smbus write+0x27c/0x530 i2c smbus xfer+0x43a/0xa40 i2c smbus xfer+0x19e/0x340 i2cdev ioctl smbus+0x38f/0x7f0 i2cdev ioctl+0x35e/0x680 x64 sys ioctl+0x147/0x1e0 do syscall 64+0xcf/0x15a0 entry SYSCALL 64 after hwframe+0x76/0x7e
Bug 2: i2c-stub I2C SMBUS I2C BLOCK DATA OOB (drivers/i2c/i2c-stub.c) stub xfer() implements .smbus xfer directly and only clamps block[0] against 256-command, not I2C SMBUS BLOCK MAX. With block[0]=0xff and command=0 the loop accesses block[1+i] for i up to 254, far past the 34-byte union.
UBSAN: array-index-out-of-bounds in drivers/i2c/i2c-stub.c:223:44 index 34 is out of range for type ' u8 [34]' Call Trace: ubsan handle out of bounds+0xd7/0x120 stub xfer+0x1971/0x198f [i2c stub] i2c smbus xfer+0x306/0xa40 i2c smbus xfer+0x19e/0x340 i2cdev ioctl smbus+0x38f/0x7f0 i2cdev ioctl+0x35e/0x680 x64 sys ioctl+0x147/0x1e0 do syscall 64+0xcf/0x15a0 entry SYSCALL 64 after hwframe+0x76/0x7e
Both traces reproduced on v7.0-rc6+i2c/for-current with KASAN+UBSAN.
Found an issue in the description? Have something to add? Feel free to write us 👾

Related Identifiers

AZL-103661

Affected Products

Kernel