CVE-2026-53340

What it actually does

This is a local denial-of-service vulnerability in the Linux kernel i.MX I2C controller driver. During runtime power-management suspend, the driver disables the I2C controller clock before switching the pin-control state to sleep. If the pinctrl sleep-state transition fails, suspend is aborted while the clock remains disabled, leaving the hardware in an inconsistent state. Subsequent access to the I2C hardware can then trigger a kernel crash or system instability. The issue affects availability only; it does not directly provide confidentiality or integrity impact, privilege escalation, or remote code execution.

Why it matters to the business

Systems using affected Linux kernels with the i.MX I2C driver can crash or become unstable when runtime power-management paths are exercised, potentially disrupting embedded, industrial, automotive, IoT, or appliance workloads that depend on i.MX-based hardware. Because exploitation requires local low-privileged access and there is no known public exploitation or KEV listing, urgency is lower than for remotely exploitable flaws, but availability-sensitive devices should still prioritize kernel updates or mitigations to reduce outage risk.

How an attack unfolds

An attacker who already has local access to a vulnerable system, with enough privileges to cause or influence runtime power-management activity involving the i.MX I2C controller, attempts to trigger the vulnerable suspend path. The vulnerable driver disables the controller clock and then attempts to move the pinctrl state to sleep. If that pinctrl transition fails, the suspend operation aborts without re-enabling the clock. The system is then left with the I2C controller hardware inaccessible despite the kernel believing it may still be usable. When the kernel or a user-triggered operation later accesses the affected I2C hardware, the inconsistent clock and pinctrl state can result in a crash, causing denial of service.

How to fix it

Update to a Linux kernel version that includes the upstream fix for the i2c-imx runtime power-management ordering issue. The corrected behavior switches the pinctrl state before disabling the clock during runtime suspend, and restores pinctrl state consistently if clock enable fails during runtime resume. If a vendor kernel is used, apply the vendor-provided kernel update or backport the specific i2c: imx driver fix. Where immediate patching is not possible, consider disabling runtime power management for the affected i.MX I2C device, disabling unused I2C controllers, restricting local shell access, and limiting access to power-management controls such as sysfs runtime PM interfaces. Fixed versions were not provided in the input, so consult the relevant Linux distribution, board support package, or device vendor advisory for exact patched kernel releases.

How to confirm the fix worked

Confirm that deployed kernels include the patched i2c-imx driver change by checking the vendor kernel changelog, package advisory, or source tree for the fix that reorders pinctrl sleep-state selection before clock disable in i2c_imx_runtime_suspend() and restores pinctrl consistency in i2c_imx_runtime_resume(). Verify the running kernel version with standard system inventory tooling and compare it against the vendor-fixed release. On representative non-production hardware, exercise suspend/resume and runtime PM paths for the affected I2C controller and confirm there are no kernel oops, panic, bus lockups, or i2c-imx clock/pinctrl errors in kernel logs. Also verify any temporary mitigation, such as disabling runtime PM for the affected I2C device, remains in effect after reboot.

Typical attack path

1. Obtain local access to a Linux system running an affected kernel on hardware using the i.MX I2C controller driver.
2. Identify that runtime power management is enabled for the affected I2C device.
3. Trigger runtime suspend/resume activity for the i.MX I2C controller, directly or indirectly through device access, power-management interfaces, or workloads that exercise the bus.
4. Induce or encounter a failed pinctrl transition during runtime suspend, leaving the I2C clock disabled while suspend is aborted.
5. Cause subsequent access to the affected I2C hardware, resulting in kernel crash or system instability.

How to detect it

Look for evidence of kernel instability around i.MX I2C runtime power-management events. Useful log sources include kernel ring buffer output, persistent system journal entries, syslog, device watchdog/reset logs, crash dumps, and embedded platform management logs. Search for i2c-imx driver messages, pinctrl state transition failures, clock enable/disable errors, runtime PM suspend or resume failures, kernel oops or panic records, and unexplained reboots following I2C activity. Because this vulnerability does not have a unique public exploit signature and may also be triggered accidentally by hardware or driver state, detection should focus on correlation: local user activity or power-management interface access followed by i2c-imx/pinctrl/clock errors and then a kernel crash, panic, watchdog reset, or reboot. If crash dumps are available, examine stack traces for i2c_imx_runtime_suspend(), i2c_imx_runtime_resume(), runtime PM, pinctrl, clk, or I2C transfer paths.

• i2c_imx_runtime_suspend
• i2c_imx_runtime_resume
• i2c-imx
• pinctrl_pm_select_sleep_state
• runtime PM suspend failed
• runtime PM resume failed
• failed to select sleep state
• failed to select default state
• clk_enable failed
• clock enable failed
• kernel panic
• Kernel panic
• Oops:
• watchdog: watchdog did not stop
• /sys/bus/i2c/devices/
• /sys/devices/platform/
• power/control

What your security team should do

• Inventory Linux systems and embedded devices using i.MX-based hardware or the i2c-imx kernel driver.
• Prioritize remediation for availability-critical appliances, industrial systems, IoT gateways, and embedded devices where a crash could interrupt operations.
• Apply vendor kernel updates or backport the upstream Linux kernel i2c-imx runtime PM fix once available for the relevant platform.
• If patching is delayed, disable runtime power management for affected I2C devices where operationally acceptable and restrict local access to power-management interfaces.
• Monitor kernel logs for i2c-imx, pinctrl, clk, runtime PM, kernel oops, panic, or watchdog reset messages that may indicate attempted triggering or spontaneous exposure.
• Because EPSS is very low and the issue is not in CISA KEV, treat this as a targeted local availability risk rather than an internet-scale emergency, unless the affected devices are safety- or uptime-critical.