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
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 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
qualitative
Red Hat
5.5 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 08, 2026 - 04:33 vuln.today
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)

AnalysisAI

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.

Technical ContextAI

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.

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.

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

Share

CVE-2026-53293 vulnerability details – vuln.today

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