CVE-2026-80678
largeRace condition in Linux kernel i2c-imx driver on NXP i.MX SoCs
CVE-2026-80678 is a race-condition and error-handling flaw in the Linux kernel's i2c-imx driver for NXP i.MX I2C controllers: i2c_imx_reg_slave() assigned i2c_imx->slave before a runtime-resume call that could fail, leaving a stale pointer that made all subsequent slave registrations fail with -EBUSY. Because the driver shares its interrupt, the i2c_imx_isr() handler can run concurrently and dereference the pointer, and the prior error-path fix (an unlocked NULL assignment) could race with the handler to cause a NULL pointer dereference and kernel crash. A local actor able to exercise I2C slave registration on an i.MX system can thus trigger failed registrations or a kernel crash (denial of service), consistent with the high 8.4 CVSS score. Affected systems are Linux deployments on NXP i.MX SoCs that run kernels including the buggy i2c-imx slave-registration code and use its I2C slave functionality. No public proof of concept is known, EPSS puts 30-day exploitation probability at 0.1%, and the flaw is not in CISA KEV, so no in-the-wild exploitation is currently reported.
What to do: Obtain a kernel update from your distribution or i.MX BSP vendor that includes the upstream i2c-imx race fix, rather than applying the earlier incomplete error-path patch. Check whether your i.MX device uses the i2c-imx driver in I2C slave mode (device tree slave registration and kernel I2C slave config); systems using only I2C master mode are largely unaffected. As an interim measure on unpatched boards, avoid initiating I2C slave registration or re-registration after runtime-resume failures.
| Linux kernel (kernel.org; CNA-assigned) Linux kernel - i2c-imx driver (NXP i.MX I2C controller) | — |
Order-of-magnitude estimate by the model from install counts, market share and public scan data it knows; verify before quoting.
In the Linux kernel, the following vulnerability has been resolved: i2c: imx: Fix slave registration race and error handling 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.
- Vector
- CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
In the news0 stories
No ingested article mentions this CVE yet.