CVE-2026-53293

What it actually does

This is a Linux kernel amdgpu driver denial-of-service flaw in the handling of the AMDGPU_INFO_READ_MMR_REG information path. The vulnerable code used unsafe locking and allocation behavior around the GPU reset semaphore and memory-management lock, including copying data to user space while holding a lock, allocating memory while holding the reset semaphore, and using a non-blocking reset lock instead of waiting for reset completion. A local user or process with access to the affected DRM/amdgpu device interface may be able to trigger lock inversion, stalls, or deadlock conditions in kernel GPU-driver code, potentially causing GPU hangs, process stalls, degraded graphics/compute availability, or broader system instability depending on workload and kernel behavior.

Why it matters to the business

The main risk is service disruption on Linux systems using affected AMD GPUs, especially workstations, VDI hosts, GPU compute nodes, rendering systems, or servers where graphics or GPU acceleration is operationally important. Successful exploitation could interrupt user sessions, crash or hang GPU-dependent applications, reduce node availability, or require service or host restarts. There is no public evidence of exploitation or known ransomware use, and the EPSS score is currently very low, but the issue should still be remediated through normal kernel maintenance because kernel driver deadlocks can affect availability and operational reliability.

How an attack unfolds

An attacker first needs local code execution or the ability to run an untrusted process on a Linux system that exposes the affected AMD GPU DRM device interface. The attacker opens the relevant DRM render or card device and invokes amdgpu information queries that reach the AMDGPU_INFO_READ_MMR_REG handling path. By timing or repeatedly issuing requests around GPU reset or memory-management activity, the attacker attempts to exercise the flawed lock ordering and reset-handling behavior. If successful, the kernel driver may block while holding locks or semaphores, allocate memory in an unsafe context, or fail to wait properly for reset completion, leading to a deadlock or hang. The resulting impact is denial of service rather than data theft or privilege escalation based on the available description.

How to fix it

Upgrade to a Linux kernel version or vendor kernel package that includes the upstream amdgpu fix for AMDGPU_INFO_READ_MMR_REG locking and reset handling. Because no exact affected product list or fixed package versions were provided, use the distribution or appliance vendor’s security advisory for this CVE and apply the corrected kernel from the supported update channel. Reboot into the fixed kernel after installation; merely installing the package is not sufficient if the vulnerable kernel remains running. Where immediate patching is not possible, reduce exposure by limiting local shell access, restricting untrusted workloads on GPU-enabled systems, tightening permissions and group membership for /dev/dri/card* and /dev/dri/renderD* devices where operationally feasible, disabling unnecessary GPU passthrough or compute access, and isolating high-risk multi-user GPU workloads until patched.

How to confirm the fix worked

Confirm the running kernel, not only the installed kernel package, has been updated to a vendor build that contains the amdgpu fix. Validate by checking the active kernel version with uname -r, comparing it against the distribution advisory, and confirming the system has been rebooted after patching. On source-built kernels, verify that the amdgpu driver includes the fix corresponding to upstream commit 361b6e6b303d4b691f6c5974d3eaab67ca6dd90e or the vendor backport equivalent. Confirm AMD GPU device access is limited to expected users and services by reviewing /dev/dri permissions and group membership. After remediation, run normal GPU workloads and monitor kernel logs for amdgpu hangs, lockdep warnings, hung tasks, GPU reset loops, or DRM errors.

Typical attack path

1. Gain local ability to execute code on a Linux system using the affected amdgpu kernel driver.
2. Confirm that AMD GPU DRM device nodes are present and accessible, such as render or card devices under /dev/dri/.
3. Open the DRM/amdgpu device from a user-space process.
4. Issue crafted or repeated amdgpu information requests that exercise the AMDGPU_INFO_READ_MMR_REG path.
5. Trigger the vulnerable locking/reset interaction during GPU reset or memory-management activity.
6. Cause the amdgpu driver, GPU workloads, or potentially the host graphics stack to hang or become unstable.

How to detect it

Look for evidence of local attempts to stress or abuse the amdgpu DRM interface and for resulting kernel-driver instability. Useful sources include kernel logs, systemd journal, auditd logs, EDR telemetry, process execution records, and GPU workload scheduler logs. Search for bursts of amdgpu or DRM errors, GPU reset loops, hung-task warnings, lockdep reports, processes repeatedly opening /dev/dri/card* or /dev/dri/renderD*, and unexplained termination or stalling of GPU-dependent applications. If auditd or eBPF telemetry records device access, correlate suspicious local processes with repeated opens or ioctls against DRM device nodes shortly before amdgpu resets or hangs. Because the vulnerability is a denial-of-service condition and the public description does not provide a unique exploit payload, detection should focus on behavioral indicators and timing correlation rather than a single definitive signature.

• AMDGPU_INFO_READ_MMR_REG
• /dev/dri/card0
• /dev/dri/renderD128
• amdgpu: GPU reset
• amdgpu: ring gfx timeout
• amdgpu: failed to lock reset domain
• amdgpu: device wedged
• amdgpu: GPU fault detected
• drm: GPU recovery disabled
• INFO: task hung in
• blocked for more than 120 seconds
• possible circular locking dependency detected
• BUG: sleeping function called from invalid context
• kernel: amdgpu
• kernel: drm

What your security team should do

• Prioritize patching Linux systems with AMD GPUs that support shared users, untrusted local workloads, VDI, GPU compute, rendering, or production desktop services.
• Use vendor kernel advisories to identify affected distributions and install the fixed kernel package, then reboot into the patched kernel.
• Inventory GPU-enabled Linux assets by looking for loaded amdgpu modules and /dev/dri device exposure.
• Restrict access to DRM device nodes and remove unnecessary users from video, render, or equivalent GPU-access groups until remediation is complete.
• Monitor for repeated amdgpu GPU resets, hung tasks, lockdep warnings, or unexplained GPU workload stalls as potential signs of attempted triggering or operational impact.
• Treat exploitation as local denial of service based on current intelligence; do not over-prioritize above remotely exploitable or privilege-escalation kernel vulnerabilities unless the affected systems are operationally critical.
• Track EPSS and vendor advisories for changes, as exploit availability is currently not reported but kernel-driver DoS proof-of-concept code may emerge after patch analysis.