Skip to main content

Linux Kernel amdgpu CVE-2026-53293

| EUVDEUVD-2026-39898 MEDIUM
Improper Locking (CWE-667)
2026-06-26 Linux GHSA-qxgc-w63m-xvqr
5.5
CVSS 3.1 · NVD
View

Attack ChainAIDerived

Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain

  1. Access
    Gain local user session
  2. Delivery
    Obtain DRM device node access (video/render group)
  3. Exploit
    Issue AMDGPU_INFO_READ_MMR_REG ioctl during concurrent GPU reset
  4. Execution
    Trigger inverted semaphore/mm_lock ordering
  5. Persist
    Kernel deadlock or panic
  6. Impact
    System crash (DoS)

Vulnerability Assessment

Weakness
CWE
ASVS 5.0
V15 - Secure Coding and Architecture Proper locking
Exploitation Conditions

Exploitation requires: (1) a system with an AMD GPU installed and the amdgpu kernel module loaded; (2) local user access with permission to open the DRM device node (/dev/dri/renderD* or /dev/dri/card*), which typically requires membership in the 'video' or 'render' OS group, or equivalent CAP_SYS_ADMIN; (3) the kernel version must fall within the affected stable branch ranges listed above. Exploitation is limited to a local denial-of-service (kernel deadlock/panic) - there is no confidentiality or integrity impact. The race-condition nature of the locking bugs means reliable triggering may require concurrent GPU reset activity, slightly increasing effective attack complexity beyond what AC:L suggests on paper. Remote exploitation is not possible.

Impact

Real-world risk is moderate-to-low despite the CVSS 5.5 score. The CVSS vector (AV:L/AC:L/PR:L) confirms exploitation is strictly local and requires low-privilege access to the DRM device node - typically membership in the 'video' or 'render' group, or equivalent. The availability impact is High, meaning a successful trigger produces a kernel deadlock or panic (full system crash). EPSS at 0.17% (6th percentile) reflects the specialist knowledge needed to reliably trigger the race and the absence of public exploit code. There is no CISA KEV listing. The primary concern is multi-tenant or shared Linux workstations and servers with AMD GPU hardware where untrusted local users can open DRM device nodes. Cloud hypervisor environments exposing GPU passthrough to untrusted VMs warrant attention. The three separate defects compound each other: a determined local attacker may need to race the GPU reset path, slightly raising effective AC above what the CVSS AC:L implies in pure practice.

Exploit ScenarioDerived

A local user with access to the AMD GPU render node (e.g., a member of the 'render' group on a shared workstation or an unprivileged VM with GPU passthrough) issues a series of AMDGPU_INFO_READ_MMR_REG ioctl calls timed to coincide with a concurrent GPU reset event, triggering the inverted lock ordering or the allocation-under-semaphore path. The kernel deadlocks or panics, taking the entire system offline. No public exploit code is known at time of analysis.

This Month Plan within 30 days. Why: MEDIUM severity (CVSS 4.0-6.9).
Patch available 0.2% exploitation probability (EPSS)

Get an e-mail when this CVE is exploited, patched or re-scored. Free account.

Alert me

AnalysisAIv1 – Jul 08, 2026

Improper locking in the Linux kernel's amdgpu DRM driver allows a local low-privileged user to trigger a kernel deadlock or system crash via the AMDGPU_INFO_READ_MMR_REG ioctl. Three distinct concurrency defects exist: inverted lock ordering between the reset semaphore and mm_lock (permitting copy_to_user() under lock), memory allocation while holding the reset semaphore, and use of down_read_trylock() where a blocking wait is required. No public exploit code has been identified and EPSS is 0.17%, placing this firmly in opportunistic-rather-than-targeted risk territory.

RemediationAI

The primary remediation is upgrading to a patched Linux kernel version: 6.6.141, 6.12.91, 6.18.33, 7.0.10, or 7.1 (or later), as provided by the upstream stable tree at https://git.kernel.org/stable/. Distribution-specific kernels from Red Hat, Ubuntu, SUSE, Debian, and others will ship backported fixes on their own schedules - check respective security advisories. If immediate patching is not possible, a targeted compensating control is to restrict access to the AMD DRM render nodes: tighten group membership on /dev/dri/renderD* and /dev/dri/card* so only fully trusted users can open them, effectively raising the privilege bar to PR:H in practice. Blacklisting the amdgpu module ('blacklist amdgpu' in /etc/modprobe.d/) eliminates the attack surface entirely but renders the AMD GPU non-functional - acceptable for headless servers where the GPU is unused. Neither workaround is suitable long-term; kernel upgrade remains the only definitive fix.

Affected VersionsENISA

Linux 9e823f307074c0f82b5f6044943b0086e3079bed <0ef196a208385b7d7da79f411c161b04e97283e2
Linux 6.6.55 <6.6.141
Linux 6.10.14 <6.11
Linux patch: 6.6.141
Linux 17a98c942cb106ec08564e8f43b5470a4dd5d3f6
Linux patch: 6.12.91
Linux patch: 6.18.33
Linux patch: 7.0.10
Linux 9a98563345697bdb1d3410ff428473b2e781f4db
Linux patch: 7.1
Linux patch: 0
Linux 9e823f307074c0f82b5f6044943b0086e3079bed <61957c2e467b39b528a290016367d32a433fa846
Linux 6.11.3 <6.12
Linux 6.12
Linux 9e823f307074c0f82b5f6044943b0086e3079bed <5c29d20470d4566d1b68df57097d642d01f8b427
Linux 8361e3f7882876d98ba98cae0d3149450dd80912 <8c4254c8f5836e77ae83e7fc037f02b69f7a0977
Linux 9e823f307074c0f82b5f6044943b0086e3079bed <a31c3feb54b15a90232e497ad0e27e8a82052d8d

Affected Packages

euvd linux fix: 6.6.141, 6.11, 6.12

Source: OSV (Open Source Vulnerabilities)

Affects your stack

Affects 1 package in euvd

Checking this CVE against your own stacks and servers is part of the Basic plan and up.

Technical ContextAI · show details

The amdgpu kernel DRM driver (CPE: cpe:2.3:a:linux:linux:*) exposes device information via the AMDGPU_INFO_READ_MMR_REG ioctl. This code path coordinates access using two synchronisation primitives: a reset semaphore (protecting GPU reset state) and an mm_lock (protecting memory-map state). CWE-667 (Improper Locking) covers three specific issues here: (1) the acquisition order of these primitives was reversed, causing copy_to_user() - a sleeping, preemptible operation - to execute while the mm_lock was held, violating kernel locking discipline; (2) kmalloc-style memory allocation was performed while the reset semaphore was held, a situation that can cause AB-BA deadlock under memory pressure; and (3) down_read_trylock() was used, meaning if a GPU reset was in progress the path would proceed without waiting, leading to use-under-reset conditions. The fix, cherry-picked from upstream commit 361b6e6b303d4b691f6c5974d3eaab67ca6dd90e, reorders lock acquisition, defers allocation outside the semaphore scope, and replaces trylock with a blocking down_read.

Know when the next one hits your stack

  • Watch products and get an email when something new is published
  • Check this CVE against your own stack and servers
  • Exploit and PoC references, threat intelligence from 22 sources

No credit card · 7-day full trial

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 ioctl access requires low privilege (DRM group); no confidentiality or integrity impact; kernel deadlock produces high availability loss.

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
Red Hat 5.5 MEDIUM

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

4
CVSS changed
Jul 08, 2026 - 04:07 NVD
5.5 (MEDIUM)
Patch available
Jun 26, 2026 - 21:02 EUVD
CVE Published
Jun 26, 2026 - 19:40 nvd
MEDIUM 5.5
CVE Published
Jun 26, 2026 - 19:40 cve.org
UNKNOWN (no severity yet)

DescriptionNVD

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

drm/amdgpu: fix AMDGPU_INFO_READ_MMR_REG

There were multiple issues in that code.

First of all the order between the reset semaphore and the mm_lock was wrong (e.g. copy_to_user) was called while holding the lock.

Then we allocated memory while holding the reset semaphore which is also a pretty big bug and can deadlock.

Then we used down_read_trylock() instead of waiting for the reset to finish.

(cherry picked from commit 361b6e6b303d4b691f6c5974d3eaab67ca6dd90e)

Threat Intelligence Overview

EPSS Score
0.2%
Top 94% exploitable
Prevalence
Medium
Linux kernel ubiquitous, but amdgpu driver narrows to AMD GPU systems
Data Quality
5 sources
Confidence: Medium

How this decision was reached

The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.

SignalValue
Severity MEDIUM
CISA KEV No
Public POC No
EPSS 0.2%
Patch available Yes
Active threat No
Deciding rule
MEDIUM severity (CVSS 4.0-6.9)
What every action level means
Emergency Immediate action required. Criteria: CRITICAL + in CISA KEV (actively exploited) without patch, OR CRITICAL + EPSS > 30% without patch, OR CRITICAL + active threat signals without patch.
Act Now Prioritize within 24-48h. Criteria: in KEV with patch available, OR CRITICAL + public POC, OR HIGH + EPSS > 10%, OR CRITICAL + active threat, OR any CRITICAL severity.
This Week Schedule remediation this week. Criteria: HIGH severity (CVSS 7.0-8.9). Patch within normal change window.
This Month Plan within 30 days. Criteria: MEDIUM severity (CVSS 4.0-6.9), lower exploitation probability. Include in regular patch cycle.
Monitor Track and reassess. Criteria: LOW severity (CVSS 0.1-3.9), minimal exploitation risk. No immediate action needed.

SSVC AssessmentENISA

SSVC Decision· derived
Defer
Exploitation· derived
None
System Exposure· derived
Small
Automatable· derived
No
Human Impact· derived
Medium

Priority Score

28
Low Medium High Critical
KEV: 0
EPSS: 0
CVSS: +28
PoC: 0
Weaponized: 0
Threat intel: 0
Gov advisory: 0

Attack Technique

Information disclosure occurs when an application unintentionally exposes sensitive data that aids attackers in reconnaissance or directly compromises security.

Vendor StatusVendor

SUSE

Severity: Moderate
Product Status
Image SLES15-SP7-Azure-3P Image SLES15-SP7-Azure-Basic Image SLES15-SP7-Azure-Standard Image SLES15-SP7-HPC-Azure Affected
Image SLES15-SP7-BYOS-Azure Image SLES15-SP7-BYOS-GCE Image SLES15-SP7-CHOST-BYOS-Aliyun Image SLES15-SP7-CHOST-BYOS-Azure Image SLES15-SP7-CHOST-BYOS-EC2 Image SLES15-SP7-CHOST-BYOS-GCE Image SLES15-SP7-CHOST-BYOS-GDC Image SLES15-SP7-CHOST-BYOS-SAP-CCloud Image SLES15-SP7-EC2 Image SLES15-SP7-EC2-ECS-HVM Image SLES15-SP7-GCE Image SLES15-SP7-HPC-BYOS-Azure Image SLES15-SP7-HPC-BYOS-EC2 Image SLES15-SP7-HPC-BYOS-GCE Image SLES15-SP7-Hardened-BYOS-Azure Image SLES15-SP7-Hardened-BYOS-EC2 Image SLES15-SP7-Hardened-BYOS-GCE Image SLES15-SP7-SAPCAL-Azure Image SLES15-SP7-SAPCAL-EC2 Image SLES15-SP7-SAPCAL-GCE Affected
Image SLES15-SP7-SAP-Azure Image SLES15-SP7-SAP-Azure-3P Image SLES15-SP7-SAP-BYOS-Azure Image SLES15-SP7-SAP-BYOS-EC2 Image SLES15-SP7-SAP-BYOS-GCE Image SLES15-SP7-SAP-EC2 Image SLES15-SP7-SAP-GCE Image SLES15-SP7-SAP-Hardened-Azure Image SLES15-SP7-SAP-Hardened-BYOS-Azure Image SLES15-SP7-SAP-Hardened-BYOS-EC2 Image SLES15-SP7-SAP-Hardened-BYOS-GCE Image SLES15-SP7-SAP-Hardened-GCE Affected
SUSE Linux Enterprise Desktop 15 SP7 Fixed
SUSE Linux Enterprise High Availability Extension 15 SP7 Fixed

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