CVE-2026-53377 closes a Linux kernel GPU-recovery flaw that can leave Qualcomm Adreno hardware stuck after a hang, causing later graphics work to time out instead of restoring the device. The fix is already present in Linux 6.18.32, Linux 7.0.9, and mainline Linux 7.1, according to the CVE record published by kernel.org and indexed by the National Vulnerability Database on July 19, 2026.
For Windows users, this is not a Windows graphics-driver vulnerability. It concerns the Linux
The practical audience is narrower but important: administrators and enthusiasts running Linux natively on Snapdragon hardware, developers using Qualcomm-based Linux boards, and maintainers shipping custom kernels for devices that use the upstream MSM DRM stack. On affected builds, a single GPU submission that hangs at the wrong moment can leave the accelerator in a bad state until a later power-management transition—or a restart—finally resets it.
The underlying bug sits in
Before this patch, that recovery sequence was conditional on
That sounds like a reasonable optimization until a minimal workload triggers the fault. As patch author Anna Maniscalco explained in the proposal sent to the Linux graphics and ARM MSM mailing lists in February, a ring containing only one submitted job can hang, have its fence incremented by recovery handling, and then appear to have no work remaining. The driver would then skip recovery and depend on the GPU entering runtime suspend and later waking when fresh work arrived.
That dependency is the defect. There is no guarantee the GPU will suspend and resume before another application, compositor, browser process, or graphics task submits more commands. If the Adreno hardware remained hung, the next submission could simply hit another timeout.
The upstream change removes the activity check. It now retires completed and failed submissions, calls the driver’s recovery operation, and replays surviving submissions regardless of whether the GPU is currently regarded as active.
In code terms, the patch is modest: 20 lines added and 22 removed. In operational terms, it turns an eventual recovery path into an immediate, deterministic one when the driver has already concluded a hang occurred.
CVE-2026-53377 should not be read as evidence of a newly documented remote-code-execution flaw, privilege-escalation issue, or data-disclosure bug. The public technical description is about failure to reset a GPU after a detected hang. Its clearest consequence is availability and reliability: graphics workloads can remain wedged, later submissions can time out, and an affected system may require manual intervention.
That does not make the update optional in managed environments. GPU hangs are disruptive even when they are not directly exploitable. On a desktop, the user may see an application crash, a frozen compositor, failed video acceleration, or a display session that never recovers properly. On an embedded device, kiosk, development board, or appliance using an Adreno GPU, persistent graphics failure can become a service outage.
The Linux kernel’s own DRM documentation describes GPU resets as necessary when hardware bugs, application bugs, or faults across the graphics stack leave a device unusable. It also makes clear that recovery has to propagate errors through the driver stack so user-mode components can decide whether to recreate contexts, report device loss, or stop sending work to the failed context.
The important point is that CVE-2026-53377 improves the kernel-side prerequisite: after the driver detects this particular stalled state, it must actually attempt the reset rather than wait for unrelated runtime power management to create another opportunity.
That leaves several practical scenarios:
Administrators should avoid treating a package name alone as proof of exposure or remediation. The relevant source file is
CVE-2026-53377 affects the Linux kernel’s open-source MSM DRM driver. A Snapdragon X laptop running Windows 11 is not protected or remediated by updating a Linux kernel, because Windows uses a separate vendor driver and display architecture. Likewise, installing a fixed Linux kernel inside a normal WSL distribution does not patch the Windows host’s Qualcomm graphics driver.
There are still edge cases worth separating. A dual-boot Snapdragon PC running Linux natively can be affected when it uses the upstream MSM driver. Developers booting Linux on Qualcomm reference hardware, ARM laptops, phones, tablets, or embedded boards may also be in scope. Virtual machines and WSL installations require assessment based on their actual GPU presentation model, not the physical GPU in the host machine.
That is a useful reminder for cross-platform fleets: GPU brand is not enough to establish CVE exposure. The operating system, active driver, virtualization method, kernel branch, and device enablement stack determine whether a given advisory applies.
If a system has already exhibited Adreno hangs, capture logs before and after updating. The useful indicators are DRM hangcheck messages, MSM GPU recovery messages, fence timeouts, application-level
That distinction is the real value of CVE-2026-53377. It does not promise an Adreno workload will never stall. It ensures that a stall involving a lone submission no longer strands the GPU simply because the driver briefly decides there is nothing left to do.
For Windows users, this is not a Windows graphics-driver vulnerability. It concerns the Linux
drm/msm driver, the open-source Direct Rendering Manager driver used with Qualcomm Snapdragon and Adreno GPUs on Linux. Native Windows on Snapdragon systems uses Qualcomm’s Windows display stack, while standard WSL graphics acceleration does not expose this Linux drm/msm driver directly to a Linux guest.The practical audience is narrower but important: administrators and enthusiasts running Linux natively on Snapdragon hardware, developers using Qualcomm-based Linux boards, and maintainers shipping custom kernels for devices that use the upstream MSM DRM stack. On affected builds, a single GPU submission that hangs at the wrong moment can leave the accelerator in a bad state until a later power-management transition—or a restart—finally resets it.
A Recovery Worker That Could Decide Not to Recover
The underlying bug sits in drivers/gpu/drm/msm/msm_gpu.c, specifically in the driver’s GPU hang-recovery worker. The MSM driver detects a stalled command ring, advances the relevant fence, retires completed work, resets or recovers the GPU, and then replays outstanding valid submissions.Before this patch, that recovery sequence was conditional on
msm_gpu_active(gpu). If the driver concluded that there was no active work remaining after it advanced the fence for the hung ring, the worker could exit without actually calling the GPU recovery routine.That sounds like a reasonable optimization until a minimal workload triggers the fault. As patch author Anna Maniscalco explained in the proposal sent to the Linux graphics and ARM MSM mailing lists in February, a ring containing only one submitted job can hang, have its fence incremented by recovery handling, and then appear to have no work remaining. The driver would then skip recovery and depend on the GPU entering runtime suspend and later waking when fresh work arrived.
That dependency is the defect. There is no guarantee the GPU will suspend and resume before another application, compositor, browser process, or graphics task submits more commands. If the Adreno hardware remained hung, the next submission could simply hit another timeout.
The upstream change removes the activity check. It now retires completed and failed submissions, calls the driver’s recovery operation, and replays surviving submissions regardless of whether the GPU is currently regarded as active.
In code terms, the patch is modest: 20 lines added and 22 removed. In operational terms, it turns an eventual recovery path into an immediate, deterministic one when the driver has already concluded a hang occurred.
Why a Hang Recovery Issue Has a CVE
The CVE language calls this a vulnerability, but the published record does not currently include a CVSS score, severity rating, CWE classification, exploit scenario, or an NVD technical assessment. That distinction matters for patch triage.CVE-2026-53377 should not be read as evidence of a newly documented remote-code-execution flaw, privilege-escalation issue, or data-disclosure bug. The public technical description is about failure to reset a GPU after a detected hang. Its clearest consequence is availability and reliability: graphics workloads can remain wedged, later submissions can time out, and an affected system may require manual intervention.
That does not make the update optional in managed environments. GPU hangs are disruptive even when they are not directly exploitable. On a desktop, the user may see an application crash, a frozen compositor, failed video acceleration, or a display session that never recovers properly. On an embedded device, kiosk, development board, or appliance using an Adreno GPU, persistent graphics failure can become a service outage.
The Linux kernel’s own DRM documentation describes GPU resets as necessary when hardware bugs, application bugs, or faults across the graphics stack leave a device unusable. It also makes clear that recovery has to propagate errors through the driver stack so user-mode components can decide whether to recreate contexts, report device loss, or stop sending work to the failed context.
The important point is that CVE-2026-53377 improves the kernel-side prerequisite: after the driver detects this particular stalled state, it must actually attempt the reset rather than wait for unrelated runtime power management to create another opportunity.
The Affected Window Starts at Linux 5.19
Kernel.org’s affected-version data identifies Linux 5.19 as the first affected upstream release. The issue remains present through earlier builds in the Linux 6.18 and 7.0 stable series, with fixed releases identified as Linux 6.18.32 and Linux 7.0.9. Linux 7.1 contains the original upstream fix.That leaves several practical scenarios:
- Systems running Linux 6.18 should update to 6.18.32 or a later maintenance release in that series.
- Systems running Linux 7.0 should update to 7.0.9 or later.
- Systems already on Linux 7.1 or later include the upstream resolution, assuming their vendor kernel has not altered or reverted the relevant MSM DRM code.
- Devices using long-term, vendor-maintained, Android-derived, or board-specific kernels need a backport review rather than a simple version comparison.
Administrators should avoid treating a package name alone as proof of exposure or remediation. The relevant source file is
drivers/gpu/drm/msm/msm_gpu.c; the meaningful validation is whether the recovery worker still wraps its reset-and-replay sequence in the former msm_gpu_active(gpu) condition.Windows on Snapdragon and WSL Are Not the Patch Target
WindowsForum readers may reasonably connect “MSM,” “Adreno,” and “Snapdragon” with Windows on Arm PCs. But the component boundary is decisive here.CVE-2026-53377 affects the Linux kernel’s open-source MSM DRM driver. A Snapdragon X laptop running Windows 11 is not protected or remediated by updating a Linux kernel, because Windows uses a separate vendor driver and display architecture. Likewise, installing a fixed Linux kernel inside a normal WSL distribution does not patch the Windows host’s Qualcomm graphics driver.
There are still edge cases worth separating. A dual-boot Snapdragon PC running Linux natively can be affected when it uses the upstream MSM driver. Developers booting Linux on Qualcomm reference hardware, ARM laptops, phones, tablets, or embedded boards may also be in scope. Virtual machines and WSL installations require assessment based on their actual GPU presentation model, not the physical GPU in the host machine.
That is a useful reminder for cross-platform fleets: GPU brand is not enough to establish CVE exposure. The operating system, active driver, virtualization method, kernel branch, and device enablement stack determine whether a given advisory applies.
Patch the Kernel, Then Watch the Recovery Path
For affected Linux systems, the remediation is straightforward: deploy a vendor kernel containing the fix, reboot into it, and verify the running version. Teams maintaining custom images should backport the stable patch rather than attempt a workaround through runtime power-management settings.If a system has already exhibited Adreno hangs, capture logs before and after updating. The useful indicators are DRM hangcheck messages, MSM GPU recovery messages, fence timeouts, application-level
VK_ERROR_DEVICE_LOST reports, and compositor failures. The patch should not be expected to prevent every underlying GPU hang; it changes what happens after the hang has been detected.That distinction is the real value of CVE-2026-53377. It does not promise an Adreno workload will never stall. It ensures that a stall involving a lone submission no longer strands the GPU simply because the driver briefly decides there is nothing left to do.
References
- Primary source: NVD / Linux Kernel
Published: 2026-07-20T01:03:10-07:00
NVD - CVE-2026-53377
nvd.nist.gov
- Security advisory: MSRC
Published: 2026-07-20T01:03:10-07:00
Original feed URL
Security Update Guide - Microsoft Security Response Center
msrc.microsoft.com
