Look up another CVE · open CVE-2026-93287 in the interactive tracker
CVE-2026-93287
i2c: smbus: reject oversized block transfers in the common path
Published 2026-09-24 (24 days ago) by the Linux kernel CNA. Subsystem drivers/i2c. Debian urgency: not yet assigned.
What to do, per Debian release
Debian's own status for CVE-2026-93287 in every release this site tracks, and what each one means in practice. Every status below is the one the Debian Security Team publishes for this CVE. source
| Release | Status | Version | What this means |
|---|---|---|---|
| Debian 12bookworm | fixedDLA-4841-1 · 2026-10-17 · text | 6.1.190-1 | Update the kernel and reboot. DLA-4841-1 shipped the fix on 2026-10-17, in 6.1.190-1. A running kernel keeps the old code until the machine restarts. |
| Debian 13trixie | fixedDSA-6528-1 · 2026-09-29 · text | 6.12.111-1 | Update the kernel and reboot. DSA-6528-1 shipped the fix on 2026-09-29, in 6.12.111-1. A running kernel keeps the old code until the machine restarts. |
| Debian 14forky | fixed | 7.1.3-1 | Update the kernel and reboot. Fixed in 7.1.3-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 7.1.3-1 | Update the kernel and reboot. Fixed in 7.1.3-1. A running kernel keeps the old code until the machine restarts. |
| Debian 12bookworm · linux-6.12 | fixedDLA-4817-1 · 2026-10-04 · text | 6.12.111-1~deb12u1 | Update the kernel and reboot. DLA-4817-1 shipped the fix on 2026-10-04, in 6.12.111-1~deb12u1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
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: <TASK> __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 </TASK> 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: <TASK> __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 </TASK> Both traces reproduced on v7.0-rc6+i2c/for-current with KASAN+UBSAN.
Where it lives
The fix touches these files. If the subsystem is one you do not use, the practical exposure is lower, though the package is still the vulnerable one.
drivers/i2c/i2c-core-smbus.c
- What this is
- I2C SUBSYSTEMMAINTAINERS section matched on drivers/i2c/* · linux-i2c@vger.kernel.org · Maintained
- Kernel module
- i2c_core
Check it on the machine
grep -w CONFIG_I2C /boot/config-$(uname -r)Reads the booted kernel's own configuration, on the machine and nowhere else. =y is built in, =m is a module, and an is not set line means the code is not there.
lsmod | grep -w i2c_corePrints a line if that module is loaded right now, and nothing if it is not. One that is not loaded can still be loaded later by anything that needs it.
Show whether Debian builds this, per release
Debian builds this, but not on every flavour. At least one release below builds the code on some of its kernel flavours and not on others, so the answer depends on the architecture and flavour installed.
- bookwormYnot built on amd64/cloud-amd64, arm64/cloud-arm64
- trixie, forky, sidBnot built on amd64/cloud-amd64, arm64/cloud-arm64
- bookworm · linux-6.12Ynot built on amd64/cloud-amd64, arm64/cloud-arm64
- Y
- built in where it is built at all; some flavours do not build it
- B
- built in on some, a module on others, absent on the rest
- Build switch
- CONFIG_I2C
From the configuration Debian publishes for every kernel flavour it builds. It covers only the architectures Debian ships a linux-config package for, and nothing about a kernel you built yourself. Debian's own status above stays authoritative about the source package.MAINTAINERS kbuild Makefiles Debian linux-config packages
Signals
- Published
- 2026-09-24 (24 days ago)source
- CVSS
- 7.8 high
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:Hsource recompute it - Attack vector
- local (AV:L)source
- EPSS
- 0.13%, higher than 2.3% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- not yet assignedsource
- Subsystem
- drivers/i2c
Upstream fixes
The versions the CNA records as introducing and fixing this, and the commit for each. source
| Introduced | Fixed in | Commit |
|---|---|---|
| 2.6.33 | 5.10.271 | 856dffcc097b |
| 2.6.33 | 5.15.222 | 356875e33f2c |
| 2.6.33 | 6.1.189 | 72ca5e0b8b7a |
| 2.6.33 | 6.6.158 | df077253f640 |
| 2.6.33 | 6.12.111 | f09edffba97d |
| 2.6.33 | 6.18.53 | c4b478bc50b7 |
| 2.6.33 | 7.1 | 3051cd060fa4 |
Debian advisories
| Advisory | Date | Shipped to | Debian |
|---|---|---|---|
| DLA-4841-1 | 2026-10-17 | bookworm 6.1.190-1 | tracker |
| DLA-4817-1 | 2026-10-04 | bookworm 6.12.111-1~deb12u1 | tracker |
| DSA-6528-1 | 2026-09-29 | trixie 6.12.111-1 | tracker |
Why the CNA scored it this way
Quoted from the kernel CNA's own scoring file, word for word. A highlighted metric carries the most severe value CVSS v3.1 defines for it, which is what pushes the score up. source
- AV:LAttack vector, local
- Attacker-controlled data is data->block[0] copied from the I2C_SMBUS ioctl in i2cdev_ioctl_smbus() (i2cdev_ioctl → i2cdev_ioctl_smbus → i2c_smbus_xfer → __i2c_smbus_xfer). That byte is supplied by the local process, not by a network protocol or a remote I2C slave.
- AC:LAttack complexity, low
- A single I2C_SMBUS ioctl with attacker-chosen block[0] (e.g. 0xfe) is consumed in __i2c_smbus_xfer() before any length check, so trace_smbus_write() memcpy()s block[0]+1 bytes and native callbacks such as stub_xfer() index block[1+i] with that length. There is no race or uninfluenced hardware failure.
- PR:LPrivileges required, low
- i2cdev_open() and i2cdev_ioctl() contain no capable() check; I2C_SMBUS is allowed to whoever can open /dev/i2c-N. That node is commonly 0660 group i2c (i2c-tools udev), so an unprivileged i2c-group user reaches i2cdev_ioctl_smbus() without root or a user-namespace capability.
- UI:NUser interaction, none
- The attacker opens /dev/i2c-N and issues the I2C_SMBUS ioctl with a crafted i2c_smbus_ioctl_data themselves; no separate victim action is required.
- S:UScope, unchanged
- Overflows land in the host kernel's i2cdev_ioctl_smbus() stack union and in the smbus_write trace-event buffer handled by that same kernel. This is ordinary local kernel memory corruption, not a VM, IOMMU, or sandbox-authority crossing.
- C:HConfidentiality impact, high
- With block[0]=0xfe, trace_smbus_write() memcpy()s 255 bytes from the 34-byte union i2c_smbus_data temp on i2cdev_ioctl_smbus()'s stack, disclosing 221 bytes of adjacent kernel stack. stub_xfer() I2C_SMBUS_I2C_BLOCK_DATA writes likewise read block[1+i] past that union.
- I:HIntegrity impact, high
- The same memcpy writes 255 bytes into smbus_write's 34-byte __entry->buf, overflowing the ftrace event by 221 bytes. stub_xfer() I2C_SMBUS_I2C_BLOCK_DATA reads write past temp.block[33] on i2cdev_ioctl_smbus()'s kernel stack, a stack overflow that can corrupt return state.
- A:HAvailability impact, high
- The 221-byte out-of-bounds read/write in trace_event_raw_event_smbus_write() and the stub_xfer() store past union i2c_smbus_data.block[33] produce a kernel oops/panic, matching the KASAN and UBSAN reports cited in the fix.