CVE-2026-80919 in Linux
Summary
by MITRE • 09/09/2026
In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: fix recursive ww_mutex acquire in amdgpu_devcoredump_format
When dumping IB contents from a hung job, amdgpu_devcoredump_format() acquired the VM root PD's reservation via amdgpu_vm_lock_by_pasid() and then, for each IB, called amdgpu_bo_reserve() on the BO backing the IB. Both reservations are reservation_ww_class_mutex objects and neither used a ww_acquire_ctx, which trips lockdep:
WARNING: possible recursive locking detected -------------------------------------------- kworker/u128:0 is trying to acquire lock: ffff88838b16e1f0 (reservation_ww_class_mutex){+.+.}-{4:4},
at: amdgpu_devcoredump_format+0x1594/0x23f0 [amdgpu]
but task is already holding lock: ffff8882f82681f0 (reservation_ww_class_mutex){+.+.}-{4:4},
at: amdgpu_devcoredump_format+0x1594/0x23f0 [amdgpu]
Possible unsafe locking scenario: CPU0 ---- lock(reservation_ww_class_mutex); lock(reservation_ww_class_mutex);
*** DEADLOCK *** May be due to missing lock nesting notation
Workqueue: events_unbound amdgpu_devcoredump_deferred_work [amdgpu]
Call Trace: __ww_mutex_lock.constprop.0 ww_mutex_lock amdgpu_bo_reserve amdgpu_devcoredump_format+0x1594 [amdgpu]
amdgpu_devcoredump_deferred_work+0xea [amdgpu]
The two reservations are on different BOs in the captured trace, so the splat is a lockdep-correctness warning, not an observed deadlock. It becomes a real self-deadlock whenever the IB BO shares its dma_resv with the root PD (the always-valid case, see amdgpu_vm_is_bo_always_valid()): amdgpu_bo_reserve(abo) re-acquires the same ww_mutex without a ticket and blocks forever. With amdgpu.gpu_recovery=0 the timeout handler refires every ~2 s and each invocation produces this splat, drowning the kernel ring buffer.
Now that amdgpu_vm_lock_by_pasid() takes a drm_exec context, move the IB dumping into a separate helper that locks the root PD and every IB BO together in a single drm_exec ticket. DRM_EXEC_IGNORE_DUPLICATES handles IB BOs that share a dma_resv (e.g. always-valid BOs, or two IBs backed by the same BO). Every lock is now a top-level acquire under one ww_acquire_ctx, so the recursive ww_mutex condition is gone, and the per-IB amdgpu_bo_reserve()/amdgpu_bo_unref() dance -- including a BO refcount leak on the amdgpu_bo_reserve() failure path -- is removed.
(cherry picked from commit d6bf4242731219ee08ce54c365631e395486651e)
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 09/09/2026
The Linux kernel driver for AMD GPU hardware, specifically the amdgpu subsystem, contained a critical concurrency flaw within its device core dump functionality. The vulnerability manifested in the amdgpu_devcoredump_format function, which is responsible for capturing and formatting information about instruction buffers from hung jobs to aid in debugging system hangs. During this process, the code attempted to acquire multiple reservation locks associated with different buffer objects without properly managing their nesting hierarchy using a ww_acquire context. Specifically, the function first acquired the reservation lock for the virtual memory root page directory via amdgpu_vm_lock_by_pasid and subsequently iterated through each instruction buffer to reserve its backing buffer object using amdgpu_bo_reserve. Both of these operations target locks belonging to the reservation_ww_class_mutex class, which is designed to prevent deadlocks by enforcing strict locking order rules. However, because neither operation utilized a ww_acquire_ctx to track lock nesting, the kernel's lock dependency validator, known as lockdep, flagged this as a potential recursive locking violation.
This technical flaw represents a classic case of improper synchronization primitives usage leading to potential system instability. While initial testing indicated that the splat was primarily a correctness warning rather than an immediately observable deadlock in most scenarios, the situation becomes severe under specific conditions. When an instruction buffer's backing buffer object shares its dma_resv structure with the root page directory—a condition often met by always-valid buffers—the code attempts to re-acquire the same ww_mutex without a ticket and outside of any acquire context. This results in a self-deadlock where the kernel thread blocks indefinitely waiting for a lock it already holds but cannot release due to the missing nesting annotation. Furthermore, if GPU recovery is disabled via the amdgpu.gpu_recovery=0 parameter, the timeout handler repeatedly retries this operation every two seconds, causing continuous generation of these warnings and flooding the kernel ring buffer with error messages, which can degrade system performance and obscure other critical logs.
From a security and reliability perspective, this vulnerability aligns with CWE-667, Improper Locking, as it involves incorrect usage of locking mechanisms that leads to resource contention or deadlock conditions. In terms of attack vectors, while not directly exploitable for remote code execution in the traditional sense, such kernel-level deadlocks can be leveraged by local attackers to cause a denial of service against the entire system by triggering GPU hangs and subsequent infinite loops within the kernel's error handling paths. This behavior is consistent with ATT&CK technique T1499, Endpoint Denial of Service, where an adversary might exploit resource exhaustion or system instability to disrupt availability. The lack of proper lock context management violates fundamental principles of concurrent programming in the Linux kernel, which relies on ww_mutexes to ensure that complex locking hierarchies are respected and deadlocks are avoided through ticket-based ordering.
The resolution involves a structural refactoring of how locks are acquired during the core dump process. By introducing a separate helper function, developers ensured that all necessary reservations for both the root page directory and each instruction buffer backing object are locked together within a single drm_exec context using one ww_acquire_ctx. This approach guarantees that all lock acquisitions occur at the same nesting level, thereby eliminating the recursive locking condition detected by lockdep. Additionally, the fix incorporates DRM_EXEC_IGNORE_DUPLICATES handling to safely manage cases where multiple buffers share the same dma_resv structure, such as always-valid buffers or shared instruction buffer objects. Beyond resolving the deadlock risk, this change also eliminates a per-buffer reference count leak that occurred on failure paths of amdgpu_bo_reserve calls, thereby improving overall memory management integrity and reducing the likelihood of resource exhaustion issues in long-running systems.