CVE-2026-31655

What it actually does

This is a local denial-of-service flaw in the Linux kernel power-domain driver for NXP i.MX8MP platforms. The vulnerable driver can allow the NOC_HDCP clock to be disabled during power-domain transitions, which may cause the NoC ADB400 port power-down handshake to hang. When triggered, the system can become unresponsive or require a reboot. The issue affects availability only; it does not provide code execution, privilege escalation, data disclosure, or data modification by itself.

Why it matters to the business

Systems running affected Linux kernels on impacted i.MX8MP-based hardware may experience hangs or forced reboots, disrupting embedded, industrial, edge, media, or appliance workloads. Because exploitation requires local access and there is no known public exploit or CISA KEV listing, broad internet-scale risk is low; however, environments that run untrusted local workloads, shared devices, kiosks, or containerized/edge applications on affected hardware should treat this as an operational availability risk.

How an attack unfolds

An attacker first needs local access to an affected Linux system running on impacted i.MX8MP hardware. They then trigger activity that causes the relevant power domain and HDCP/NoC-related clock path to transition, such as repeated suspend/resume, runtime power-management cycling, or access patterns that exercise the affected block. Because the vulnerable kernel may power down the NOC_HDCP clock during the NoC ADB400 handshake, the platform can hang. The attacker’s practical outcome is denial of service: the device may freeze, stop processing workloads, or require manual or watchdog-initiated reboot. There is no indication from the provided data that this vulnerability is remotely exploitable or used by ransomware or named threat actors.

How to fix it

Upgrade to a Linux kernel or vendor BSP release that includes the fix for the imx8mp-blk-ctrl power-domain driver, specifically the change that keeps the NOC_HDCP clock enabled. No exact fixed package versions were provided, so use the applicable Linux distribution, hardware vendor, or board-support-package advisory to identify the corrected release for your platform. Where immediate upgrade is not possible, backport the upstream kernel patch to the deployed kernel branch. Temporary mitigations include restricting local shell access, limiting untrusted workloads on affected devices, reducing exposure to user-triggerable suspend/resume or runtime power-management transitions, and using watchdog recovery to reduce outage duration. These mitigations reduce impact but do not replace applying the kernel fix.

How to confirm the fix worked

Confirm exposure by verifying that the device is running on affected i.MX8MP-class hardware and uses a vulnerable Linux kernel containing the imx8mp-blk-ctrl power-domain driver without the NOC_HDCP clock fix. Validate remediation by checking the installed kernel package or BSP source includes the patch that keeps NOC_HDCP enabled, then reboot into the fixed kernel. Functional validation should include repeated suspend/resume, runtime power-management cycling, and workloads that exercise the relevant multimedia or HDCP-related block while monitoring for kernel hangs, watchdog resets, RCU stalls, or soft lockups. Package scanners should rely on vendor fixed-version metadata when available, since no fixed versions were provided in the input.

Typical attack path

1. Obtain local access to an affected Linux system on i.MX8MP-based hardware.
2. Identify or induce operations that exercise the affected power-domain path, such as runtime power management, suspend/resume, or related multimedia/HDCP block activity.
3. Repeatedly trigger the relevant power-domain transition or clock-gating sequence.
4. Cause the NoC ADB400 power-down handshake to hang because the NOC_HDCP clock is not kept enabled.
5. Force a system availability failure, resulting in a hang, watchdog reset, or required manual reboot.

How to detect it

There are no known public exploit indicators, named threat actors, ransomware use, or KEV evidence associated with this issue in the provided data. Detection should focus on signs of prior availability impact rather than traditional compromise. Review kernel logs, persistent journal logs, serial console output, watchdog logs, BMC or device-management logs, and crash/reboot telemetry for unexplained hangs, watchdog resets, soft lockups, RCU stalls, or power-management failures on i.MX8MP systems. Correlate these events with local user activity, workload starts, suspend/resume cycles, runtime power-management events, or access to multimedia/HDCP-related components. Because successful exploitation may leave only a hang or reset, absence of logs does not rule out triggering; serial console and persistent logging are important for confirmation.

• imx8mp-blk-ctrl
• NOC_HDCP
• ADB400
• watchdog: BUG: soft lockup
• rcu: INFO: rcu_sched detected stalls
• rcu: INFO: rcu_preempt detected stalls
• Kernel panic - not syncing
• Watchdog detected hard LOCKUP
• watchdog: watchdog0: watchdog did not stop
• Power domain imx8mp-blk-ctrl

What your security team should do

• Prioritize patching affected i.MX8MP-based Linux devices where uptime is critical or where local users, containers, plugins, or applications are not fully trusted.
• Inventory embedded, edge, appliance, and industrial Linux deployments to determine whether they run affected i.MX8MP hardware and vulnerable kernel/BSP builds.
• Coordinate with hardware and OS vendors to obtain a kernel/BSP release containing the imx8mp-blk-ctrl NOC_HDCP clock fix, or backport the patch for long-lived embedded branches.
• Until patched, restrict local access and untrusted workload execution on affected devices, especially access that can trigger suspend/resume or runtime power-management transitions.
• Enable watchdogs and operational monitoring to detect and recover from hangs, while recognizing that watchdog reboot is only an availability mitigation.
• Monitor vendor advisories because fixed versions were not supplied and may vary by distribution, BSP, and kernel branch.
• Treat this as lower exploit-priority than remotely exploitable kernel flaws because EPSS is very low, exploit maturity is listed as none, and it is not in CISA KEV; nevertheless, address it in normal embedded platform maintenance cycles.