CVE-2026-53293 Overview
CVE-2026-53293 affects the Linux kernel's AMD GPU (amdgpu) direct rendering manager (DRM) driver. The flaw resides in the handling of the AMDGPU_INFO_READ_MMR_REG ioctl, which allowed userspace to read memory-mapped registers. The code contained multiple concurrency and memory-management defects: an inverted lock ordering between the reset semaphore and mm_lock, memory allocation performed while holding the reset semaphore, and use of down_read_trylock() instead of waiting for a GPU reset to complete. The upstream fix was backported from commit 361b6e6b303d.
Critical Impact
Local users invoking the amdgpu ioctl interface could trigger deadlocks or unsafe memory operations, leading to denial-of-service conditions on affected systems.
Affected Products
- Linux kernel builds including the amdgpu DRM driver
- Distributions shipping stable kernels prior to the referenced backport commits
- Systems using AMD GPUs relying on the DRM userspace interface
Discovery Timeline
- 2026-06-26 - CVE-2026-53293 published to NVD
- 2026-06-30 - Last updated in NVD database
Technical Details for CVE-2026-53293
Vulnerability Analysis
The vulnerability is a kernel-level race condition and locking defect [Race Condition / Kernel Vulnerability] in the amdgpu driver path servicing the AMDGPU_INFO_READ_MMR_REG query. Three distinct issues coexist in the same code path. First, the acquisition order between the reset semaphore and mm_lock was reversed, causing copy_to_user() to run while holding a lock it should not hold. Second, memory allocation occurred while the reset semaphore was held, which can block indefinitely and lead to deadlock under memory pressure. Third, the code used down_read_trylock() instead of waiting on the reset semaphore, so callers could proceed during an in-flight GPU reset.
Root Cause
The root cause is improper synchronization primitive usage inside the ioctl handler. Holding the reset semaphore across a user-space copy operation and across a kernel allocation violates the lock's contract. The trylock variant compounds the problem by returning immediately when a reset is in progress rather than blocking until state is coherent. Together these defects create unsafe sequences that can wedge the driver.
Attack Vector
A local unprivileged user with access to the /dev/dri/renderD* device node can issue the AMDGPU_INFO_READ_MMR_REG ioctl to reach the vulnerable path. Concurrent invocations during GPU reset activity can produce a deadlock or expose inconsistent register state. Exploitation does not require elevated privileges beyond DRM device access. Refer to the upstream commits listed in the references for the exact code changes that resolve the flaw.
Detection Methods for CVE-2026-53293
Indicators of Compromise
- Kernel log entries showing amdgpu hangs, hung task warnings, or GPU reset failures around DRM ioctl activity
- Repeated AMDGPU_INFO_READ_MMR_REG ioctl invocations from unexpected or non-graphics processes
- Userspace processes stuck in uninterruptible sleep (D state) waiting on amdgpu semaphores
Detection Strategies
- Monitor dmesg for amdgpu reset activity coinciding with task hangs or soft lockups
- Audit process access to /dev/dri/renderD* and /dev/dri/card* nodes for anomalous callers
- Track kernel version and patch state across the Linux fleet to identify unpatched hosts
Monitoring Recommendations
- Ingest kernel logs into a centralized platform and alert on amdgpu soft-lockup or hung-task signatures
- Correlate DRM ioctl usage patterns with user session context to detect abusive local activity
- Track kernel package versions via configuration management to confirm remediation coverage
How to Mitigate CVE-2026-53293
Immediate Actions Required
- Update to a Linux stable kernel release containing the backport commits referenced in the NVD entry
- Restrict local access to the system, since exploitation requires a local account with DRM device access
- Rebuild and redeploy custom or hardened kernels that carry the amdgpu driver from vulnerable base versions
Patch Information
The fix is a cherry-pick of upstream commit 361b6e6b303d4b691f6c5974d3eaab67ca6dd90e, which corrects the lock ordering, removes allocation under the reset semaphore, and replaces down_read_trylock() with a blocking wait. Stable-tree backports are available in the following commits: 0ef196a208385b7d7da79f411c161b04e97283e2, 5c29d20470d4566d1b68df57097d642d01f8b427, 61957c2e467b39b528a290016367d32a433fa846, 8c4254c8f5836e77ae83e7fc037f02b69f7a0977, and a31c3feb54b15a90232e497ad0e27e8a82052d8d. Apply the vendor kernel update from your distribution once available.
Workarounds
- Limit membership in the video and render groups to trusted users to reduce local exposure
- Blacklist or unload the amdgpu module on systems that do not require AMD GPU acceleration
- Apply mandatory access control policies (SELinux, AppArmor) to restrict which processes can open /dev/dri/renderD*
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.
