PT-2026-104884 · Azure Linux · Kernel
Publicado
2026-09-24
·
Atualizado
2026-09-24
Nenhuma
Não há classificações de severidade ou métricas disponíveis. Quando houver, atualizaremos as informações correspondentes na página.
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.
Encontrou algum problema na descrição? Tem algo a acrescentar? Fique à vontade para nos escrever 👾
Identificadores relacionados
Produtos afetados
Kernel