CVE-2026-53377

What it actually does

This flaw affects the Linux kernel MSM/Qualcomm Adreno DRM GPU driver recovery path. When a GPU ring hangs under specific workload conditions, the recovery worker can incorrectly decide there is no more work to process and skip full GPU recovery. If the GPU does not suspend and resume before additional work is submitted, the device can remain in a hung state and repeatedly trigger GPU timeouts. The practical technical impact is local denial of service against GPU functionality, with possible graphics/session instability, application hangs, display compositor disruption, or broader system responsiveness issues on systems using the affected msm DRM driver.

Why it matters to the business

Systems that rely on Qualcomm/MSM GPU acceleration may experience user-visible instability, frozen graphical sessions, degraded device performance, or service interruption if a local workload triggers the GPU hang condition. The issue is not currently listed in CISA KEV, has no known ransomware association, has very low EPSS, and has no reported exploit maturity, so broad internet-scale exploitation is unlikely; however, organizations operating Linux-based desktops, mobile/embedded devices, kiosks, or edge systems with affected Qualcomm GPUs should still patch during normal kernel maintenance because the failure mode can disrupt availability.

How an attack unfolds

An attacker needs the ability to run code or submit GPU work on a system using the affected Linux msm DRM driver. They submit a GPU workload that causes a ring hang, especially a case where a single submitted job causes the hang. The kernel recovery worker advances the fence for the hung ring, sees no remaining work, and exits early instead of forcing GPU recovery. Because the GPU may not suspend and resume before more work arrives, the device remains in a hung state. Subsequent GPU submissions then encounter repeated timeouts or continued hangs, causing graphics applications, compositors, or GPU-dependent workloads to stall until the GPU is reset by another mechanism, the driver is reloaded, or the system is rebooted.

How to fix it

Update to a Linux kernel build that includes the upstream fix for the msm DRM recovery logic, specifically the change that makes the driver always recover the GPU rather than skipping recovery when no additional work appears pending. If vendor kernels are used, obtain the corrected kernel from the OS, device, BSP, Android, embedded Linux, or appliance vendor. Where immediate patching is not possible, reduce exposure by limiting untrusted local code execution, restricting access to GPU/DRM device nodes where operationally feasible, disabling unnecessary GPU acceleration for untrusted workloads, isolating browser or containerized GPU access, and monitoring for recurring MSM GPU timeout or hang events. No exact package fixed versions were provided in the input, so remediation should be tracked against the relevant vendor kernel advisory or kernel package changelog referencing the drm/msm GPU recovery fix.

How to confirm the fix worked

Confirm that the running kernel includes the msm DRM fix by checking the vendor kernel changelog, package advisory, or source tree for the patch described as making drm/msm always recover the GPU. Validate that all systems using Qualcomm/MSM GPU hardware have been rebooted into the updated kernel, since kernel package installation alone is insufficient. On Linux systems, compare the running kernel version from `uname -r` with the patched vendor release, and verify the installed kernel package is the expected fixed build. Functional validation can include running representative GPU workloads and confirming that induced or historical GPU hangs no longer leave the GPU in a persistently timed-out state. Also review kernel logs after patching to ensure recurring msm GPU hang and timeout messages have stopped.

Typical attack path

1. Gain local execution capability or access to an interface that can submit work to the GPU, such as a graphical session, compute workload, browser GPU process, or application using DRM/GPU acceleration.
2. Run or trigger a crafted workload that causes the MSM/Adreno GPU ring to hang.
3. Rely on the vulnerable recovery behavior where the recovery worker exits early instead of always recovering the GPU.
4. Submit additional GPU work while the GPU remains hung.
5. Cause repeated GPU timeout events, graphical instability, application freezes, or local denial of service until recovery, driver reload, session restart, or reboot occurs.

How to detect it

To determine whether the issue may already have been triggered, review kernel and system logs for repeated MSM/Adreno GPU hang, timeout, fault, or recovery messages. Useful sources include `dmesg`, `journalctl -k`, `/var/log/kern.log`, `/var/log/messages`, Android kernel logs where applicable, crash telemetry, watchdog reset records, compositor logs, and application crash reports from GPU-accelerated processes. Look for a pattern of GPU timeout messages followed by continued hangs or repeated timeout events rather than successful recovery. Correlate events with user sessions, browser GPU processes, graphical compositor restarts, container workloads with GPU access, or applications that submitted GPU work shortly before the hang. There are no known public exploit artifacts, threat actor reports, ransomware links, or network indicators for this vulnerability; detection should focus on local kernel telemetry and availability symptoms.

• drm/msm
• msm_gpu
• MSM DRM
• Adreno
• GPU hang
• gpu hang
• GPU timeout
• gpu timeout
• ring hang
• hung ring
• recover_worker
• GPU recovery
• gpu recovery
• faulting ring
• dmesg | grep -Ei 'drm/msm|msm_gpu|adreno|gpu.*hang|gpu.*timeout|ring.*hang|gpu.*recover'
• journalctl -k | grep -Ei 'drm/msm|msm_gpu|adreno|gpu.*hang|gpu.*timeout|ring.*hang|gpu.*recover'

What your security team should do

• Inventory Linux, Android-derived, embedded, kiosk, edge, and appliance systems using Qualcomm/MSM/Adreno GPUs and the msm DRM kernel driver.
• Prioritize patching systems where untrusted users, applications, browser workloads, containers, or remote desktop sessions can access GPU acceleration.
• Track the fix through the appropriate OS, device, BSP, or vendor kernel channel and ensure systems reboot into the corrected kernel.
• Until patched, restrict untrusted access to GPU device nodes and avoid exposing GPU acceleration to workloads that do not require it.
• Create monitoring for repeated kernel GPU hang, timeout, and msm DRM recovery messages as an availability-impact signal.
• Because this is not KEV-listed, not associated with ransomware, and has very low EPSS, handle through standard availability-risk patch cycles unless affected systems support critical operations or have broad local multi-user access.