CVE-2026-53056

What it actually does

This is a Linux kernel availability flaw in the Qualcomm MSM Display Processing Unit (DPU) DRM driver. During DPU runtime suspend, the driver lowers the OPP rate to 0, which can drop the MMCX voltage rail to a minimum performance level while the DPU core clock remains configured at a high frequency. On resume, the clock can be re-enabled without restoring a matching voltage vote, leaving the display hardware running at an unsustainable voltage/frequency combination. The likely result is hardware instability, display subsystem failure, kernel crash, or full system reboot rather than data disclosure or privilege escalation.

Why it matters to the business

Systems using affected downstream Linux kernels with Qualcomm MSM DPU display hardware may experience unexpected crashes, reboots, display failures, or device instability when the display subsystem enters and exits low-power states. The operational risk is primarily service interruption, device downtime, and reliability impact for phones, tablets, embedded devices, kiosks, automotive/IoT systems, or other Qualcomm-based Linux platforms. Current public exploitation signals are low: EPSS is 0.00128, it is not listed in CISA KEV, and it is not known to be used in ransomware campaigns.

How an attack unfolds

An attacker would need a way to influence the affected system into repeatedly exercising the vulnerable DPU runtime suspend and resume path. In a realistic scenario, this would usually require local access, application-level access to graphics/display behavior, or control over workloads that cause display idle, power-management transitions, device bind/init timing, or repeated screen on/off cycles. The vulnerable driver can lower the MMCX rail vote during suspend while retaining a high DPU clock configuration. When the display hardware resumes, the clock may run at the prior high rate while the rail remains at a low voltage level. That mismatch can destabilize the display subsystem and may crash or reboot the host. There is no indication from the provided data of public exploit code, named threat actor use, KEV listing, or ransomware use.

How to fix it

Upgrade to a kernel or vendor firmware/software release that includes the upstream fix removing the dev_pm_opp_set_rate(dev, 0) call from dpu_runtime_suspend in the drm/msm/dpu driver. Because no exact affected product list or fixed versions were provided, use the device, SoC, distribution, Android BSP, or embedded Linux vendor advisory as the source of truth for the corrected build. Where immediate patching is not possible, consider temporary mitigations that reduce DPU runtime power transitions, such as disabling aggressive display runtime power management, avoiding display idle/off automation, or keeping affected devices on stable power/performance profiles, if supported and acceptable for power consumption and thermal constraints. These mitigations reduce exposure but do not correct the driver bug.

How to confirm the fix worked

Confirm the running kernel or device firmware contains the vendor patch for this issue. For source-based validation, inspect the Qualcomm MSM DPU runtime suspend implementation and verify that dpu_runtime_suspend no longer calls dev_pm_opp_set_rate(dev, 0). For binary/device validation, compare the installed kernel package, boot image, firmware, or BSP version against the vendor’s fixed release. After patching, perform controlled display suspend/resume, screen blank/unblank, runtime PM, and reboot-cycle testing while monitoring dmesg, journal logs, pstore/ramoops, and watchdog reset records for DPU, DRM/MSM, OPP, clock, regulator, or MMCX-related failures. A successful fix should preserve stability across repeated DPU suspend/resume cycles without kernel panics, display subsystem hangs, or unexpected resets.

Typical attack path

1. Identify a Linux-based device using the Qualcomm MSM DPU DRM driver and an affected kernel build.
2. Obtain local or application-level ability to trigger display activity, idle transitions, suspend/resume behavior, or repeated display power state changes.
3. Cause the DPU runtime suspend path to execute while the vulnerable driver drops the OPP rate/voltage vote.
4. Trigger DPU runtime resume so the core clock is re-enabled while the MMCX rail may still be at an insufficient performance level.
5. Repeat the transition or time it with initialization/bind activity until the voltage/frequency mismatch causes display instability, kernel panic, watchdog reset, or system reboot.

How to detect it

There are no known public exploitation indicators in the provided data, and exploitation may be indistinguishable from spontaneous hardware or driver instability. To assess whether the condition has occurred, review kernel and crash telemetry for unexpected reboots, watchdog resets, kernel panics, display subsystem hangs, or DRM/MSM/DPU errors that occur immediately after display idle, screen off/on, runtime suspend/resume, or boot-time device initialization. Useful sources include dmesg, systemd journal, Android logcat/kernel logs where applicable, pstore/ramoops, kdump/vmcore, watchdog reset reason registers, kernel panic logs, and fleet crash reports. Look for repeated crashes on affected Qualcomm display platforms with stack traces or messages involving the MSM DRM driver, DPU runtime power management, OPP/clock/regulator handling, or MMCX power-domain behavior. Also review local activity or applications that repeatedly manipulate display state, keep the display cycling, trigger compositor/display server restarts, or induce suspend/resume loops shortly before crashes. Absence of a clear attacker artifact does not rule out triggering of the bug; correlation with display power-management transitions is the key investigative signal.

What your security team should do

• Prioritize inventory of Qualcomm MSM DPU-based Linux, Android, embedded, kiosk, IoT, and appliance platforms, especially systems where unexpected reboot creates safety, availability, or operational impact.
• Apply vendor kernel, firmware, BSP, or OS updates that include the drm/msm/dpu runtime suspend fix; no exact fixed versions were provided in the input, so track vendor advisories closely.
• Treat this primarily as an availability and reliability vulnerability rather than a confidentiality or privilege-escalation issue unless a downstream vendor advisory states otherwise.
• For high-availability deployments, test patched images under repeated display suspend/resume and power-management cycling before broad rollout.
• Until patched, reduce unnecessary display power-state churn on exposed or critical devices where feasible.
• Monitor crash telemetry, watchdog resets, pstore/ramoops, kdump data, and kernel logs for repeated DPU/DRM/MSM failures that correlate with display idle, wake, suspend, or resume events.
• Because the CVE is not in KEV, has very low EPSS, and has no known exploit maturity in the provided data, handle through normal kernel maintenance urgency unless affected devices are business-critical or crash-sensitive.