CVE-2026-53293: Linux AMD GPU Driver Denial-of-Service Vulnerability

Technical summary

CVE-2026-53293 addresses multiple synchronization defects in the AMDGPU_INFO_READ_MMR_REG code path within the Linux kernel's AMD GPU (amdgpu) driver. The vulnerability involves three distinct but related flaws: (1) incorrect lock ordering where copy_to_user() is invoked while holding mm_lock, creating potential deadlock scenarios; (2) memory allocation performed under the reset semaphore, which can trigger another deadlock condition; and (3) use of down_read_trylock() instead of properly waiting for reset completion, allowing races between reset and register read operations. These issues collectively compromise the integrity of the GPU memory-mapped register read interface and can be exploited to hang or crash the kernel.

Business impact

Organizations running production systems with AMD GPUs are exposed to denial-of-service attacks from local users. On affected systems, an unprivileged attacker can render the GPU subsystem unavailable, potentially disrupting graphics-intensive workloads, machine learning pipelines, or virtualized GPU services. The impact is contained to local exploitation and does not compromise data confidentiality or integrity, but availability loss can be significant in GPU-dependent environments such as render farms, HPC clusters, or AI inference platforms.

Affected systems

All Linux kernel versions prior to the fix commit (361b6e6b303d4b691f6c5974d3eaab67ca6dd90e) containing the AMDGPU driver are affected. The specific affected kernel branch or version threshold should be verified against the upstream Linux kernel repository and your distribution's patch history. AMD GPU hardware (RDNA, RDNA2, RDNA3, and potentially CDNA families) on affected Linux systems are in scope.

Exploitability

The vulnerability is locally exploitable and requires unprivileged user-level access; no kernel privileges, special hardware capabilities, or user interaction is needed. The attack surface is the read_mmap_registers interface, which is typically accessible to any local process. Exploitation is straightforward from a complexity standpoint—triggering concurrent access patterns or rapid register reads can reliably reproduce the deadlock or crash condition. The CVSS 3.1 score of 5.5 (MEDIUM) reflects the local-only requirement and lack of confidentiality/integrity impact, though the availability impact is high.

Remediation

Apply the kernel patch that corrects the lock and semaphore ordering, eliminates memory allocation under the reset semaphore, and replaces down_read_trylock() with appropriate blocking wait semantics. This fix (cherry-picked from commit 361b6e6b303d4b691f6c5974d3eaab67ca6dd90e) should be merged into your kernel version. Verify the specific patched kernel release for your distribution before deployment.

Patch guidance

Coordinate with your Linux distribution to identify the patched kernel version that includes commit 361b6e6b303d4b691f6c5974d3eaab67ca6dd90e or equivalent backport. For mainstream distributions (Red Hat, Ubuntu, Debian, SUSE), check security advisories and kernel updates released on or after 2026-06-26. If running upstream or custom kernels, manually cherry-pick the fix or rebase onto a kernel version containing the patch. Verify GPU functionality and stability in a non-production environment before broad rollout.

Detection guidance

Monitor kernel logs (dmesg, journalctl) for GPU driver hangs, reset failures, or deadlock warnings mentioning amdgpu or the MMIO read path. Workload monitoring tools should flag GPU tasks that suddenly hang or time out. If using performance profiling, watch for stuck kernel threads in the amdgpu driver context. Systems experiencing intermittent crashes or hangs when GPU register reads are in flight warrant investigation. No standard IDS/IPS signatures exist, but correlated hang events across multiple systems with AMD GPUs may indicate exploitation attempts.

Why prioritize this

Although the CVSS score is MEDIUM (5.5), prioritize patching GPU-enabled systems with local user access (especially shared HPC, rendering, or cloud environments). The denial-of-service impact is high—a single malicious user can disrupt critical GPU workloads for all tenants on the system. Systems with strict user isolation or single-tenant configurations can accept longer remediation timelines, but multi-tenant or high-availability setups should patch within the next maintenance window.

Risk score, explained

CVSS 3.1 assigns a score of 5.5 (MEDIUM) based on local attack vector, low privileges required, no user interaction, and high availability impact but no confidentiality or integrity loss. The score appropriately reflects that this is a denial-of-service vulnerability affecting system availability rather than data security. However, in multi-tenant environments or GPU-as-a-service deployments, the practical risk is elevated due to cross-tenant impact potential.

Frequently asked questions