Cloudanix VulnDB

CVE-2026-80678

High · 8.4

CVSS

8.4

EPSS

0.1%

Published

Aug 28, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A bug in the Linux kernel driver for certain I2C chips can let local software cause hardware setup failures or system crashes during device registration.

Exploitation
Local Privilege
Attacker needs
Local User
Complexity
Moderate
Impact
Full Compromise
Component
OS kernel
Class
Race Condition
Remediation
Patch
Effort
Low
Patch risk
Low

What it actually does

The flaw leaves a stale non-NULL slave pointer in the i2c-imx driver after a failed pm_runtime_resume_and_get call and performs the assignment outside the slave_lock critical section, allowing concurrent ISR access to observe invalid state and trigger -EBUSY registration failures or NULL pointer dereferences.

Why it matters to the business

Linux systems using the i2c-imx controller may suffer repeated slave registration failures, driver instability, or kernel crashes during I2C device initialization, disrupting hardware communication on affected kernels.

How an attack unfolds

A local attacker triggers concurrent slave registration attempts while inducing a pm_runtime failure; the window created by the early pointer assignment and lack of lock protection lets the shared-IRQ handler dereference an invalid slave pointer.

How to fix it

Apply the upstream fix that defers slave pointer assignment until after a successful resume and performs the assignment inside the slave_lock critical section; rebuild and deploy the patched kernel on all affected systems.

How to confirm the fix worked

Inspect the i2c_imx_reg_slave function in the running kernel source to confirm the assignment occurs after pm_runtime_resume_and_get succeeds and is protected by slave_lock; reproduce registration under injected resume failure conditions.

Typical attack path

  1. Local process opens I2C adapter and calls slave registration ioctl
  2. Force or wait for pm_runtime_resume_and_get failure
  3. Race with i2c_imx_isr executing under slave_lock
  4. Trigger dereference of stale or NULL slave pointer

How to detect it

Search kernel logs and dmesg for repeated I2C slave registration failures returning -EBUSY and any NULL pointer dereference reports originating from i2c_imx_isr during shared IRQ handling.

  • i2c_imx: slave registration failed with -EBUSY
  • BUG: unable to handle kernel NULL pointer dereference in i2c_imx_isr

What your security team should do

  • Apply the corrected kernel version to all hosts using i2c-imx hardware
  • Add kernel log monitoring for i2c registration errors and oops in i2c_imx_isr
  • Verify I2C slave devices initialize cleanly after the update

The record

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.

Affected packages

Ecosystem Package Introduced Fixed