UBUNTU-CVE-2026-93287: High severity ubuntu/linux vulnerability
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 i2csmbusxferemulated() but that check runs too late for tracepoints and is skipped entirely when the adapter provides a native smbusxfer implementation. This allows user-controlled oversized block lengths to reach tracepoint memcpy calls and driver callbacks unchecked. Add an early validation in i2csmbusxfer() that rejects block transfers whose caller-supplied length is zero or exceeds I2CSMBUSBLOCKMAX 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 smbuswrite tracepoint, all native smbusxfer driver implementations, and the emulated path. Two distinct bugs are fixed by this change: Bug 1: smbuswrite tracepoint OOB (include/trace/events/smbus.h) tracesmbuswrite() 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 traceeventraweventsmbuswrite+0x27c/0x530 Read of size 255 at addr ffff88800d98fcf8 by task pocsmbus/91 Call Trace: <TASK> asanmemcpy+0x23/0x80 traceeventraweventsmbuswrite+0x27c/0x530 i2csmbusxfer+0x43a/0xa40 i2csmbusxfer+0x19e/0x340 i2cdevioctlsmbus+0x38f/0x7f0 i2cdevioctl+0x35e/0x680 x64sysioctl+0x147/0x1e0 dosyscall64+0xcf/0x15a0 entrySYSCALL64afterhwframe+0x76/0x7e </TASK> Bug 2: i2c-stub I2CSMBUSI2CBLOCKDATA OOB (drivers/i2c/i2c-stub.c) stubxfer() implements .smbusxfer directly and only clamps block[0] against 256-command, not I2CSMBUSBLOCKMAX. 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: <TASK> ubsanhandleoutofbounds+0xd7/0x120 stubxfer+0x1971/0x198f [i2cstub] i2csmbusxfer+0x306/0xa40 i2csmbusxfer+0x19e/0x340 i2cdevioctlsmbus+0x38f/0x7f0 i2cdevioctl+0x35e/0x680 x64sysioctl+0x147/0x1e0 dosyscall64+0xcf/0x15a0 entrySYSCALL64afterhwframe+0x76/0x7e </TASK> Both traces reproduced on v7.0-rc6+i2c/for-current with KASAN+UBSAN.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
ubuntu/linux-aws-5.15to a version that resolves this vulnerability.Fixed in 5.15.0-1119.126~20.04.1 - Upgrade
Upgrade
ubuntu/linux-azure-5.15to a version that resolves this vulnerability.Fixed in 5.15.0-1125.134~20.04.1 - Upgrade
Upgrade
ubuntu/linux-azure-fde-5.15to a version that resolves this vulnerability.Fixed in 5.15.0-1124.133~20.04.1 - Upgrade
Upgrade
ubuntu/linux-gcp-5.15to a version that resolves this vulnerability.Fixed in 5.15.0-1120.130~20.04.1 - Upgrade
Upgrade
ubuntu/linux-hwe-5.15to a version that resolves this vulnerability.Fixed in 5.15.0-202.212~20.04.1 - Upgrade
Upgrade
ubuntu/linux-ibm-5.15to a version that resolves this vulnerability.Fixed in 5.15.0-1113.117~20.04.1 - Upgrade
Upgrade
ubuntu/linux-intel-iotg-5.15to a version that resolves this vulnerability.Fixed in 5.15.0-1114.120~20.04.1 - Upgrade
Upgrade
ubuntu/linux-lowlatency-hwe-5.15to a version that resolves this vulnerability.Fixed in 5.15.0-197.207~20.04.1 - Upgrade
Upgrade
ubuntu/linux-nvidia-tegra-5.15to a version that resolves this vulnerability.Fixed in 5.15.0-1070.72~20.04.1 - Upgrade
Upgrade
ubuntu/linux-oracle-5.15to a version that resolves this vulnerability.Fixed in 5.15.0-1116.122~20.04.1 - Upgrade
Upgrade
ubuntu/linux-riscv-5.15to a version that resolves this vulnerability.Fixed in 5.15.0-1113.117~20.04.2 - Upgrade
Upgrade
ubuntu/linuxto a version that resolves this vulnerability.Fixed in 5.15.0-202.212 - Upgrade
Upgrade
ubuntu/linux-awsto a version that resolves this vulnerability.Fixed in 5.15.0-1119.126 - Upgrade
Upgrade
ubuntu/linux-azureto a version that resolves this vulnerability.Fixed in 5.15.0-1125.134 - Upgrade
Upgrade
ubuntu/linux-azure-fdeto a version that resolves this vulnerability.Fixed in 5.15.0-1124.133 - Upgrade
Upgrade
ubuntu/linux-gcpto a version that resolves this vulnerability.Fixed in 5.15.0-1120.130 - Upgrade
Upgrade
ubuntu/linux-gketo a version that resolves this vulnerability.Fixed in 5.15.0-1115.121 - Upgrade
Upgrade
ubuntu/linux-gkeopto a version that resolves this vulnerability.Fixed in 5.15.0-1102.110 - Upgrade
Upgrade
ubuntu/linux-ibmto a version that resolves this vulnerability.Fixed in 5.15.0-1113.117 - Upgrade
Upgrade
ubuntu/linux-intel-iotgto a version that resolves this vulnerability.Fixed in 5.15.0-1114.120 - Upgrade
Upgrade
ubuntu/linux-kvmto a version that resolves this vulnerability.Fixed in 5.15.0-1111.116 - Upgrade
Upgrade
ubuntu/linux-lowlatencyto a version that resolves this vulnerability.Fixed in 5.15.0-197.207 - Upgrade
Upgrade
ubuntu/linux-nvidiato a version that resolves this vulnerability.Fixed in 5.15.0-1114.115 - Upgrade
Upgrade
ubuntu/linux-nvidia-tegrato a version that resolves this vulnerability.Fixed in 5.15.0-1070.72 - Upgrade
Upgrade
ubuntu/linux-nvidia-tegra-igxto a version that resolves this vulnerability.Fixed in 5.15.0-1059.59 - Upgrade
Upgrade
ubuntu/linux-oracleto a version that resolves this vulnerability.Fixed in 5.15.0-1116.122 - Upgrade
Upgrade
ubuntu/linux-bluefieldto a version that resolves this vulnerability.Fixed in 5.15.0-1103.105 - Upgrade
Upgrade
ubuntu/linux-intel-iot-realtimeto a version that resolves this vulnerability.Fixed in 5.15.0-1111.115 - Upgrade
Upgrade
ubuntu/linux-realtimeto a version that resolves this vulnerability.Fixed in 5.15.0-1118.127 - Upgrade
Upgrade
ubuntu/linux-aws-fipsto a version that resolves this vulnerability.Fixed in 5.15.0-1119.126+fips1 - Upgrade
Upgrade
ubuntu/linux-azure-fipsto a version that resolves this vulnerability.Fixed in 5.15.0-1125.134+fips1 - Upgrade
Upgrade
ubuntu/linux-fipsto a version that resolves this vulnerability.Fixed in 5.15.0-202.212+fips1 - Upgrade
Upgrade
ubuntu/linux-gcp-fipsto a version that resolves this vulnerability.Fixed in 5.15.0-1120.130+fips1 - Upgrade
Upgrade
ubuntu/linux-hwe-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-42.42~24.04.1 - Upgrade
Upgrade
ubuntu/linux-riscv-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-42.42.1~24.04.1 - Upgrade
Upgrade
ubuntu/linuxto a version that resolves this vulnerability.Fixed in 7.0.0-42.42 - Upgrade
Upgrade
ubuntu/linux-awsto a version that resolves this vulnerability.Fixed in 7.0.0-1016.17 - Upgrade
Upgrade
ubuntu/linux-gcpto a version that resolves this vulnerability.Fixed in 7.0.0-1016.18 - Upgrade
Upgrade
ubuntu/linux-ibmto a version that resolves this vulnerability.Fixed in 7.0.0-1017.17 - Upgrade
Upgrade
ubuntu/linux-oem-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-1017.17 - Upgrade
Upgrade
ubuntu/linux-oracleto a version that resolves this vulnerability.Fixed in 7.0.0-1015.16 - Upgrade
Upgrade
ubuntu/linux-riscvto a version that resolves this vulnerability.Fixed in 7.0.0-42.42.1 - Configuration
Validate data->block[0] in __i2c_smbus_xfer() before any tracepoint fires or driver callback runs; apply this check only to operations where the length is supplied by the caller.
Linux kernel __i2c_smbus_xfer() SMBus block transfer length validation = Reject caller-supplied lengths of zero or greater than I2C_SMBUS_BLOCK_MAX
Event History
Frequently Asked Questions
Who can exploit this issue?
An attacker needs local access and low-level privileges. The vulnerable path is reached through SMBus block-transfer operations with caller-controlled lengths, so systems that expose such operations to untrusted local users are the relevant exposure case.
Are systems using native SMBus adapter drivers affected?
Yes. The prior validation in the emulated path was skipped when an adapter supplied its own native smbus_xfer implementation, allowing oversized caller-supplied block lengths to reach driver callbacks unchecked.
What operation triggers the vulnerable path?
A caller supplies a zero or oversized length for an SMBus block transfer. Before the fix, this value could reach the smbus_write tracepoint and downstream driver callbacks before validation.
What is the immediate mitigation if an updated kernel cannot be deployed?
Restrict untrusted local users from performing SMBus block-transfer operations. The provided data does not identify a configuration-only mitigation that protects the tracepoint, native driver, and emulated paths.
How does the fix change behavior?
The kernel now rejects caller-supplied SMBus block-transfer lengths of zero or greater than I2C_SMBUS_BLOCK_MAX with -EINVAL before tracepoints fire or driver callbacks run. The validation is limited to operations where the caller supplies the length; device-provided block-read lengths are not covered by that check.