CVE-2026-80919 Overview
CVE-2026-80919 is a locking defect in the Linux kernel's AMD GPU driver (drm/amdgpu). The function amdgpu_devcoredump_format() acquired the virtual memory (VM) root page directory's reservation_ww_class_mutex via amdgpu_vm_lock_by_pasid() and then called amdgpu_bo_reserve() on each indirect buffer (IB) backing object without a ww_acquire_ctx. This pattern trips lockdep with a recursive locking warning and becomes a real self-deadlock when the IB buffer object (BO) shares its dma_resv with the root page directory.
Critical Impact
When amdgpu.gpu_recovery=0 is set, the timeout handler refires every two seconds. Each invocation can self-deadlock or flood the kernel ring buffer with lockdep splats after a GPU hang.
Affected Products
- Linux kernel drm/amdgpu driver
- Systems running AMD graphics hardware using the amdgpu kernel module
- Kernel branches prior to the fix commit d6bf424273121
Discovery Timeline
- 2026-09-09 - CVE-2026-80919 published to NVD
- 2026-09-09 - Last updated in NVD database
Technical Details for CVE-2026-80919
Vulnerability Analysis
The defect resides in amdgpu_devcoredump_format(), which dumps IB contents after a hung GPU job. The function first acquires the VM root page directory's reservation lock through amdgpu_vm_lock_by_pasid(). It then iterates over each captured IB and calls amdgpu_bo_reserve() on the backing BO. Both locks are reservation_ww_class_mutex objects, and neither call passes a ww_acquire_ctx ticket.
Lockdep reports a possible recursive locking scenario because two independent top-level acquires of the same lock class occur on the same task. In the captured trace the two reservations target different BOs, so the warning is a correctness violation rather than an observed hang. The condition becomes an actual self-deadlock whenever the IB BO shares its dma_resv with the root page directory, which is the always-valid case identified by amdgpu_vm_is_bo_always_valid(). In that path, amdgpu_bo_reserve(abo) re-enters the same ww_mutex without a ticket and blocks indefinitely.
A secondary issue on the error path leaked a BO refcount when amdgpu_bo_reserve() failed, compounding resource pressure on repeated timeouts.
Root Cause
The root cause is missing ww_acquire_ctx nesting when acquiring multiple reservation_ww_class_mutex locks. The ww_mutex API requires all sibling acquires to share a single acquire context so that the wound-wait algorithm can arbitrate contention. Acquiring two locks of the same class as independent top-level operations violates that contract.
Attack Vector
This is a locally triggered denial-of-service condition. A userspace workload that causes a GPU job to hang can invoke the devcoredump path. On kernels built with amdgpu.gpu_recovery=0, repeated timeouts drive continuous execution of the defective path, producing either a hard self-deadlock in the kworker thread or persistent ring buffer flooding. No network reachability is required.
The fix moves IB dumping into a helper that locks the root page directory and every IB BO in a single drm_exec ticket. DRM_EXEC_IGNORE_DUPLICATES handles IB BOs that share a dma_resv, so every lock becomes a top-level acquire under one ww_acquire_ctx. See Kernel Git Commit 4e9b4de and Kernel Git Commit 7152b24 for the upstream fix.
Detection Methods for CVE-2026-80919
Indicators of Compromise
- Kernel ring buffer messages containing WARNING: possible recursive locking detected referencing reservation_ww_class_mutex.
- Stack traces including amdgpu_devcoredump_format+0x1594 and amdgpu_devcoredump_deferred_work in the events_unbound workqueue.
- Blocked or hung kworker tasks observed after a GPU job timeout on AMD hardware.
Detection Strategies
- Monitor dmesg and journal logs for repeated lockdep splats tied to the amdgpu devcoredump path.
- Audit kernel build configuration for amdgpu.gpu_recovery=0, which amplifies the frequency of the defective code path.
- Track kernel versions across the fleet and flag hosts running amdgpu kernels that predate commit d6bf424273121.
Monitoring Recommendations
- Alert on GPU reset events and correlated kworker D-state processes on workstations and compute nodes using AMD GPUs.
- Ingest kernel logs into a centralized logging platform and build detections that trigger on reservation_ww_class_mutex recursive-lock warnings.
- Baseline devcoredump artifact generation frequency to detect abnormal loops caused by recurring hung jobs.
How to Mitigate CVE-2026-80919
Immediate Actions Required
- Apply the upstream kernel patch or update to a distribution kernel that has cherry-picked commit d6bf424273121.
- Avoid setting amdgpu.gpu_recovery=0 on unpatched systems, as this configuration amplifies the deadlock and log-flooding behavior.
- Reboot affected hosts after patching to ensure the corrected amdgpu module is loaded.
Patch Information
The fix is captured in the upstream Linux kernel tree. Refer to Kernel Git Commit 4e9b4de and Kernel Git Commit 7152b24. The patch introduces a drm_exec context that acquires the root page directory and all IB BOs under one ww_acquire_ctx, uses DRM_EXEC_IGNORE_DUPLICATES for shared dma_resv, and removes the per-IB amdgpu_bo_reserve()/amdgpu_bo_unref() sequence including the reference count leak on failure.
Workarounds
- Leave amdgpu.gpu_recovery at its default enabled setting so timeout handlers do not re-trigger the defective path repeatedly.
- Restrict access to workloads capable of intentionally hanging GPU jobs on shared multi-tenant hosts until patching is complete.
- Where feasible, disable devcoredump collection for the amdgpu driver on unpatched kernels to prevent execution of the affected function.
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.