Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "8.4",
  "pubDate": "2026-08-28T08:16:53.107Z",
  "pubdate": "2026-08-28T08:16:53.107Z",
  "executiveSummary": "The Linux kernel i2c-imx driver contained a critical concurrency flaw and improper error handling during slave device registration.\nThe vulnerability involves a race condition and state inconsistency occurring when pm_runtime_resume_and_get() fails, potentially leading to persistent denial-of-service or kernel null pointer dereference.\nThe issue specifically affects the i2c_imx_reg_slave() function and the i2c_imx_isr() interrupt service routine.\nAn attacker capable of triggering I2C slave registration attempts or forcing runtime PM failure could cause the i2c_imx->slave pointer to remain in a stale, non-NULL state, effectively blocking all subsequent registrations with -EBUSY errors.\nFurthermore, the shared IRQ architecture creates a window where the interrupt handler might attempt to dereference an improperly initialized or partially cleared slave pointer, resulting in a system crash.\nThis vulnerability highlights a flaw in synchronization and resource management within the I2C subsystem, emphasizing the need for atomic state transitions when modifying shared driver pointers that are accessed by asynchronous interrupt handlers.",
  "technicalDetails": "The root cause of this vulnerability lies in the improper ordering of operations within i2c_imx_reg_slave() and a lack of synchronization between the registration path and the i2c_imx_isr() interrupt handler.\nHistorically, the i2c_imx driver assigned the slave pointer before verifying the success of pm_runtime_resume_and_get(). If the runtime resume operation failed, the driver returned an error code but failed to nullify the i2c_imx->slave pointer.\nThis leaves the i2c_imx structure in a corrupted state: the kernel incorrectly assumes an active slave is registered. Because i2c_imx_reg_slave() checks if the pointer is already set to return -EBUSY, this stale pointer prevents any further successful slave registrations, resulting in a persistent Denial of Service (DoS) for I2C slave functionality.\nAdditionally, the driver utilizes a shared IRQ, meaning i2c_imx_isr() can trigger at any moment. The previous attempt to mitigate this by setting i2c_imx->slave = NULL on the error path was non-atomic relative to the interrupt handler.\nThe attack flow proceeds as follows: 1) An application initiates an I2C slave registration request. 2) The driver begins the process but encounters a failure in pm_runtime_resume_and_get(). 3) The driver reaches the error path, but due to the sequence of operations, the slave pointer remains non-NULL. 4) If an interrupt occurs simultaneously, the i2c_imx_isr() function acquires slave_lock and attempts to dereference i2c_imx->slave. If the error path cleared the pointer without proper synchronization or if the state is intermediate, the kernel attempts a NULL pointer dereference, triggering a kernel panic.\nThe remediation involves deferring the pointer assignment until after the success of the runtime PM resume operation. By wrapping the assignment of i2c_imx->slave and i2c_imx->last_slave_event within the slave_lock critical section, the driver ensures that the interrupt handler never encounters a stale or partially initialized pointer state.\nThis ensures the pointer is only visible to the ISR once it is fully initialized and guaranteed to be valid, closing the window for race conditions and preventing the accumulation of stale driver state on failed registration attempts."
}