Skip to main content

Linux Kernel CVE-2026-53377

| EUVDEUVD-2026-45450 MEDIUM
2026-07-19 Linux GHSA-9q28-3qg6-wq2f
Information Disclosure Linux Red Hat Suse
5.5
CVSS 3.1 · NVD
Share

Severity by source

NVD PRIMARY
5.5 MEDIUM
AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
vuln.today AI
5.5 MEDIUM

Local-only vector with low privileges required to submit GPU workloads; exclusively availability impact on the GPU subsystem, no confidentiality or integrity effect.

3.1 AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
4.0 AV:L/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
SUSE
MEDIUM
qualitative

Primary rating from NVD.

CVSS VectorNVD

Attack Vector
Local
Attack Complexity
Low
Privileges Required
Low
User Interaction
None
Scope
Unchanged
Confidentiality
None
Integrity
None
Availability
High

Lifecycle Timeline

5
Analysis Generated
Jul 29, 2026 - 17:08 vuln.today
CVSS changed
Jul 29, 2026 - 17:07 NVD
5.5 (MEDIUM)
Patch available
Jul 19, 2026 - 13:02 EUVD
CVE Published
Jul 19, 2026 - 10:02 nvd
MEDIUM 5.5
CVE Published
Jul 19, 2026 - 10:02 cve.org
UNKNOWN (no severity yet)

DescriptionNVD

In the Linux kernel, the following vulnerability has been resolved:

drm/msm: always recover the gpu

Previously, in case there was no more work to do, recover worker wouldn't trigger recovery and would instead rely on the gpu going to sleep and then resuming when more work is submitted.

Recover_worker will first increment the fence of the hung ring so, if there's only one job submitted to a ring and that causes an hang, it will early out.

There's no guarantee that the gpu will suspend and resume before more work is submitted and if the gpu is in a hung state it will stay in that state and probably trigger a timeout again.

Just stop checking and always recover the gpu.

Patchwork: https://patchwork.freedesktop.org/patch/704066/

AnalysisAI

Persistent GPU denial-of-service in the Linux kernel's drm/msm Qualcomm GPU driver allows a local low-privileged user to render the GPU permanently hung by submitting a single ring workload that triggers an unrecovered fault. The recover_worker function advances the hung ring's fence and early-exits when it detects no further queued work, bypassing the actual GPU reset sequence - leaving the hardware stuck until a reboot. No public exploit has been identified and EPSS is 0.15% (5th percentile), consistent with the narrow hardware and local-access prerequisites.

Technical ContextAI

The drm/msm subsystem is the Direct Rendering Manager driver for Qualcomm MSM/Snapdragon GPUs in the Linux kernel, used on embedded and mobile Linux platforms. The vulnerability is in the recover_worker function responsible for recovering from GPU ring hangs. When only a single job is submitted to a GPU command ring and that job causes a hang, recover_worker increments the fence (advancing the completion marker) and then performs an early-exit: finding no remaining queued work, it skips the actual GPU recovery sequence, assuming the GPU will naturally suspend and resume before more work arrives. This assumption is not guaranteed - if additional work is submitted before the GPU suspends, it hits a still-hung GPU and triggers another timeout. The CPE cpe:2.3:a:linux:linux identifies the affected product across stable branches. No CWE is formally assigned, but the pattern most closely matches CWE-670 (Always-Incorrect Control Flow Implementation) due to the conditional recovery path that should be unconditional.

RemediationAI

The primary fix is upgrading to Linux kernel 6.18.32 (for the 6.18.x stable branch) or 7.0.9 / 7.1 (for the 7.x branch), which include the one-line logic correction to always trigger GPU recovery unconditionally. Upstream stable patches are available at https://git.kernel.org/stable/c/132b8d51f0ffbee6e4e1ebbe1a50330aaf2dbd5d, https://git.kernel.org/stable/c/2f5c90478749dfd9a32386100b6078a364298b01, and https://git.kernel.org/stable/c/01a0d6cd7032e9993feea19fadb03ef9d5b488f2. Ubuntu users should apply USN-8593-1 via standard package management (apt update && apt upgrade linux-image). As a compensating control where immediate patching is not possible, restricting untrusted local user access to GPU devices (via device permissions or GPU resource managers) limits the ability of non-privileged users to trigger the hang condition - note this may impact legitimate GPU workloads. Periodic automated GPU reset scripts (via sysfs or driver-level reset interfaces) can reduce recovery time if hangs occur, but do not eliminate the root cause.

Same technique Information Disclosure

View all
CVE-2019-2725 CRITICAL POC
9.8
CVE-2021-34523 CRITICAL POC
9.0
CVE-2013-2251 CRITICAL POC
9.8
CVE-2017-5638 CRITICAL POC
9.8
CVE-2025-24813 CRITICAL POC
9.8
CVE-2015-1701 HIGH POC
7.8
CVE-2017-0147 HIGH POC
7.5
CVE-2014-6324 HIGH POC
8.8

Vendor StatusVendor

SUSE

Severity: Moderate
Product Status
SUSE Linux Enterprise Desktop 15 SP7 Not-Affected
SUSE Linux Enterprise Desktop 15 SP7 Not-Affected
SUSE Linux Enterprise High Availability Extension 15 SP7 Not-Affected
SUSE Linux Enterprise High Availability Extension 15 SP7 Not-Affected
SUSE Linux Enterprise High Availability Extension 16.0 Not-Affected

Share

CVE-2026-53377 vulnerability details – vuln.today
Back

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy