Look up another CVE · open CVE-2026-80678 in the interactive tracker
CVE-2026-80678
i2c: imx: Fix slave registration race and error handling
Published 2026-08-28 (2 months 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-80678 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-4777-1 · 2026-09-08 · text | 6.1.187-1 | Update the kernel and reboot. DLA-4777-1 shipped the fix on 2026-09-08, in 6.1.187-1. A running kernel keeps the old code until the machine restarts. |
| Debian 13trixie | fixed | 6.12.105-1 | Update the kernel and reboot. Fixed in 6.12.105-1. A running kernel keeps the old code until the machine restarts. |
| Debian 14forky | fixed | 7.1.8-1 | Update the kernel and reboot. Fixed in 7.1.8-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 7.1.8-1 | Update the kernel and reboot. Fixed in 7.1.8-1. A running kernel keeps the old code until the machine restarts. |
| Debian 12bookworm · linux-6.12 | fixedDLA-4788-1 · 2026-09-19 · text | 6.12.107-1~deb12u1 | Update the kernel and reboot. DLA-4788-1 shipped the fix on 2026-09-19, in 6.12.107-1~deb12u1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
In i2c_imx_reg_slave(), the slave pointer was assigned before pm_runtime_resume_and_get(). If pm_runtime_resume_and_get() failed, the error path returned without clearing i2c_imx->slave, leaving it non-NULL and causing all subsequent registration attempts to fail with -EBUSY. Additionally, because this driver uses a shared IRQ, the interrupt handler i2c_imx_isr() can execute concurrently and, after acquiring slave_lock, dereference i2c_imx->slave. The previous fix attempt added a lockless i2c_imx->slave = NULL on the error path, but that could race with the ISR under the lock and still cause a NULL pointer dereference. Fix both issues by deferring the assignment of i2c_imx->slave and i2c_imx->last_slave_event to after a successful resume, and by performing the assignment inside the slave_lock critical section. This guarantees that the slave pointer is never left stale on the error path and is always valid when observed by the interrupt handler.
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/busses/i2c-imx.c
- What this is
- FREESCALE IMX I2C DRIVERMAINTAINERS section matched on drivers/i2c/busses/i2c-imx.c · linux-i2c@vger.kernel.org · Maintained
- Kernel module
- i2c_imx
Check it on the machine
grep -w CONFIG_I2C_IMX /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_imxPrints 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.
- bookwormMnot built on amd64/amd64, amd64/cloud-amd64, amd64/rt/amd64, arm64/cloud-arm64, i386/686, i386/686-pae, i386/rt/686-pae, ppc64el/powerpc64le
- trixieMnot built on amd64/amd64, amd64/cloud-amd64, amd64/rt/amd64, arm64/cloud-arm64, armel/rpi, ppc64el/powerpc64le, ppc64el/powerpc64le-64k, riscv64/riscv64, s390x/s390x
- forky, sidMnot built on amd64/amd64, amd64/cloud-amd64, amd64/rt-amd64, arm64/cloud-arm64, loong64/loong64, ppc64el/powerpc64le, ppc64el/powerpc64le-64k, riscv64/riscv64, s390x/s390x
- bookworm · linux-6.12Mnot built on amd64/amd64, amd64/cloud-amd64, amd64/rt/amd64, arm64/cloud-arm64, ppc64el/powerpc64le, ppc64el/powerpc64le-64k
- M
- a module where it is built at all; some flavours do not build it
- Build switch
- CONFIG_I2C_IMX
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-08-28 (2 months ago)source
- CVSS
- 8.4 high
CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:Hsource recompute it - Attack vector
- local (AV:L)source
- EPSS
- 0.14%, higher than 3.1% 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 |
|---|---|---|
| 5.11 | 5.15.217 | 754bc62f72fd |
| 5.11 | 6.1.183 | cfdf6e135185 |
| 5.11 | 6.6.151 | b9f6f4883b9a |
| 5.11 | 6.12.103 | d6748f6802f3 |
| 5.11 | 6.18.44 | 12a4f0950a15 |
| 5.11 | 7.1.8 | 614ca6594e30 |
| 5.11 | 7.2 | d64ec362c369 |
Debian advisories
| Advisory | Date | Shipped to | Debian |
|---|---|---|---|
| DLA-4788-1 | 2026-09-19 | bookworm 6.12.107-1~deb12u1 | tracker |
| DLA-4777-1 | 2026-09-08 | bookworm 6.1.187-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
- The bug is in i2c_imx_reg_slave() reached from kernel i2c_slave_register() during driver probe/module bind on embedded i.MX platforms; concurrent exploitation requires local I2C bus activity on the same adapter to fire the shared IRQ handler during registration.
- AC:LAttack complexity, low
- The attacker controls the race by driving I2C slave traffic to trigger i2c_imx_isr() while registration runs, and can retry across reboots, OTA reprobes, or pm_runtime resume cycles until the unprotected slave-pointer window is hit.
- PR:NPrivileges required, none
- No Linux credentials are needed when a physically proximate attacker races automated boot-time or service-driven i2c_slave_register() calls (DT probe, IPMI SSIF/MCTP backends) on imx I2C slave-capable controllers.
- UI:NUser interaction, none
- Exploitation requires no victim interaction; automated driver probe, suspend/resume, or maintenance-triggered slave registration provides the registration side of the race without user action.
- S:UScope, unchanged
- Impact is confined to kernel memory safety violations and crash on the same host; this is not a VM escape, IOMMU bypass, or other cross-security-authority boundary.
- C:HConfidentiality impact, high
- The ISR can dereference a NULL or stale i2c_imx->slave under slave_lock when the error path races registration, violating memory safety and enabling arbitrary kernel read primitives per CVSS race/UAF guidance.
- I:HIntegrity impact, high
- Concurrent ISR handling during partial slave registration can corrupt driver state and invoke slave callbacks with inconsistent pointers, enabling heap manipulation and arbitrary kernel write or control-flow hijack beyond a simple crash.
- A:HAvailability impact, high
- NULL or stale slave dereference in i2c_imx_isr()/i2c_imx_slave_event() causes kernel oops/panic; leaving slave non-NULL after failed pm_runtime_resume_and_get() also blocks all subsequent slave registration (-EBUSY) on affected controllers.