Skip to main content
CVE Vulnerability Database
Vulnerability Database/CVE-2026-80678

CVE-2026-80678: Linux Kernel i2c-imx Race Condition Vulnerability

CVE-2026-80678 is a race condition flaw in the Linux kernel i2c-imx driver that can cause NULL pointer dereference during slave registration. This post covers technical details, affected versions, and mitigation.

Published:

CVE-2026-80678 Overview

CVE-2026-80678 is a race condition and error-handling flaw in the Linux kernel's i2c-imx driver, which supports I2C controllers on Freescale/NXP i.MX platforms. The vulnerability resides in the i2c_imx_reg_slave() function, where the i2c_imx->slave pointer is assigned before pm_runtime_resume_and_get() completes. A failed runtime power-management resume leaves a stale pointer, and the shared IRQ handler i2c_imx_isr() can concurrently dereference it under slave_lock, producing a NULL pointer dereference in kernel context.

Critical Impact

A local attacker with the ability to trigger slave registration on an i.MX system can induce a kernel NULL pointer dereference, causing memory corruption or a denial of service against the kernel.

Affected Products

  • Linux kernel builds that include the drivers/i2c/busses/i2c-imx.c driver
  • Systems using NXP/Freescale i.MX I2C controllers configured in slave mode
  • Distributions shipping affected stable kernel branches prior to the fixes referenced in the patches below

Discovery Timeline

  • 2026-08-28 - CVE-2026-80678 published to NVD
  • 2026-08-29 - Last updated in NVD database

Technical Details for CVE-2026-80678

Vulnerability Analysis

The i2c-imx driver exposes an I2C slave registration path via i2c_imx_reg_slave(). The original implementation assigned the caller-supplied slave client to i2c_imx->slave before calling pm_runtime_resume_and_get() to bring the controller out of runtime suspend. When the resume call failed, the function returned an error without clearing i2c_imx->slave. Every subsequent registration attempt then observed a non-NULL pointer and failed with -EBUSY, effectively wedging slave registration until the driver was reloaded.

A prior remediation attempted to clear the pointer on the error path without holding slave_lock. Because the driver shares its interrupt line, i2c_imx_isr() runs concurrently and dereferences i2c_imx->slave after acquiring slave_lock. The lockless write races against the ISR read, producing a NULL pointer dereference in interrupt context. The corrected fix defers the pointer assignment until after a successful pm_runtime_resume_and_get() and performs it inside the slave_lock critical section.

Root Cause

The root cause is an ordering and locking defect combining a race condition (TOCTOU-style unsynchronized state) with improper error-path cleanup. State was published before initialization succeeded, and the corrective write executed outside the lock that the shared-IRQ handler relies on for consistency.

Attack Vector

Exploitation requires local access. An actor able to invoke I2C slave registration or influence runtime PM failures on an affected i.MX system can trigger the inconsistent state. Once the race window is hit, the concurrent ISR path dereferences an invalid pointer, resulting in a kernel oops. Given the elevated CIA impact of a kernel-level fault, the flaw can be leveraged for denial of service and, under memory-corruption conditions, for further exploitation.

No public proof-of-concept exploit is available at this time. The vulnerability is described in prose because no verified exploit code has been released. Refer to the upstream stable-tree commits for the exact source-level change.

Detection Methods for CVE-2026-80678

Indicators of Compromise

  • Kernel oops or panic logs referencing i2c_imx_isr, i2c_imx_reg_slave, or a NULL pointer dereference inside drivers/i2c/busses/i2c-imx.c
  • Repeated -EBUSY returns from I2C slave registration attempts on i.MX hardware
  • Unexpected reboots or hangs on embedded i.MX-based devices following I2C peripheral initialization

Detection Strategies

  • Inventory Linux kernel versions across i.MX-based fleets and correlate against the fixed commits 12a4f09, 614ca65, 754bc62, b9f6f48, cfdf6e1, d64ec36, and d6748f68.
  • Monitor dmesg and journald for stack traces containing i2c-imx frames alongside NULL dereference signatures.
  • Enable kernel crash dumping (kdump) on production i.MX systems to preserve forensic evidence of any triggered oops.

Monitoring Recommendations

  • Ship kernel logs from embedded and edge Linux devices to a central log platform and alert on BUG:, Unable to handle kernel NULL pointer, and i2c-imx string co-occurrences.
  • Track process and driver telemetry from Linux endpoints for anomalous I2C driver reloads or module insertions that could indicate exploitation attempts.
  • Baseline expected I2C slave registration events on production devices and flag deviations.

How to Mitigate CVE-2026-80678

Immediate Actions Required

  • Identify all i.MX-based systems running Linux kernels that include drivers/i2c/busses/i2c-imx.c and prioritize them for patching.
  • Apply the upstream stable-tree fixes or the vendor kernel update that incorporates them.
  • Restrict local access to affected devices and limit which users or services can load kernel modules or interact with I2C slave interfaces.

Patch Information

The fix defers assignment of i2c_imx->slave and i2c_imx->last_slave_event until after pm_runtime_resume_and_get() succeeds, and moves the assignment inside the slave_lock critical section. Apply one of the following stable-tree patches matching your kernel branch: Kernel Patch 12a4f09, Kernel Patch 614ca65, Kernel Patch 754bc62, Kernel Patch b9f6f48, Kernel Patch cfdf6e1, Kernel Patch d64ec36, and Kernel Patch d6748f68.

Workarounds

  • Where patching is not immediately feasible, avoid registering I2C slave clients on affected i.MX controllers and disable unused I2C slave functionality via device tree or driver configuration.
  • Reduce exposure by limiting local shell access on affected embedded systems and enforcing least privilege for accounts that can interact with kernel interfaces.
  • Enable kernel hardening options such as panic_on_oops=1 on devices where a controlled reboot is preferable to running in an inconsistent state.
bash
# Verify the running kernel and check whether the i2c-imx driver is in use
uname -r
lsmod | grep -i i2c_imx

# On systems where slave functionality is not required, prevent module autoload
echo 'blacklist i2c_imx' | sudo tee /etc/modprobe.d/blacklist-i2c-imx.conf

# Harden against exploitation of kernel NULL dereferences
sudo sysctl -w kernel.panic_on_oops=1

Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

Default Legacy - Prefooter | Experience the World’s Most Advanced Cybersecurity Platform

Experience the Most Advanced Cybersecurity Platform

See how the world’s most intelligent, autonomous cybersecurity platform can protect your organization today and into the future.