CVE-2026-89820 in Linux
Summary
by MITRE • 09/16/2026
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: fix dc_lock leak on GPU reset error paths
On GPU reset, dm_suspend() takes dc_lock and leaves it for dm_resume() to drop. If amdgpu_dm_commit_zero_streams() or dm_dmub_hw_init() fails, the function returns with the lock still held. The matching resume path is then skipped, so every later dc_lock take hangs.
Release the cached DC state and unlock before returning the error.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 09/16/2026
The identified vulnerability resides within the Linux kernel's Direct Rendering Manager subsystem for AMD display hardware, specifically affecting the amdgpu driver module. This issue manifests as a resource leak involving the dc_lock mutex during GPU reset operations. The core of the problem lies in the synchronization mechanism used to manage access to Display Core state data structures. During normal operation, the dm_suspend function acquires this lock to safely suspend display components and expects that the subsequent dm_resume function will release it upon resuming from a suspended or reset state. This pattern relies on strict symmetry between suspension and resume paths to maintain system stability and prevent deadlocks.
The technical flaw occurs when specific initialization functions within the error handling path of GPU resets fail. Specifically, if amdgpu_dm_commit_zero_streams or dm_dmub_hw_init encounters an error condition, the current implementation returns immediately without releasing the previously acquired dc_lock. Because these functions are called during a reset sequence that may bypass the standard resume logic under certain failure conditions, the lock remains held indefinitely in kernel memory space. This creates a situation where the mutex is not properly released despite the operation failing to complete successfully.
The operational impact of this vulnerability is severe and can lead to system-wide instability or denial of service for display functionality. Since the dc_lock is left in an acquired state after a failed reset, any subsequent attempt by other kernel threads or processes to acquire this same lock will block indefinitely. This results in a deadlock scenario where critical display subsystem operations hang waiting for a resource that will never be released. Users may experience frozen displays, unresponsive graphical interfaces, or system hangs requiring a hard reboot. In server environments, this could affect remote management capabilities if they rely on the graphics stack for status reporting.
From a vulnerability classification perspective, this issue aligns with CWE-406, which describes improper control of resource allocation and deallocation, specifically resulting in an incomplete release of resources such as locks or semaphores. It also relates to CWE-832 regarding unlock of a locked resource that is not currently locked, although the primary failure here is the omission of the unlock operation rather than unlocking an already unlocked one. In terms of attack vectors and defensive mapping, this defect could be leveraged in denial-of-service attacks if an attacker can trigger GPU reset failures repeatedly to exhaust system resources or freeze display services. It falls under MITRE ATT&CK technique T1499, Endpoint Denial of Service, specifically through resource exhaustion via lock contention.
The resolution involves modifying the error handling paths within the affected functions to ensure that the cached Display Core state is properly released and the dc_lock mutex is explicitly unlocked before returning an error code. This ensures that regardless of whether initialization succeeds or fails, the synchronization primitive returns to its initial free state, allowing subsequent operations to proceed normally. Developers should verify that all exit points in similar suspend-resume cycles follow this pattern to prevent recurrence. Mitigation strategies for system administrators include applying kernel updates provided by their distribution vendors as soon as they become available. Until patches are applied, monitoring logs for GPU reset errors and ensuring stable power delivery can reduce the likelihood of triggering these specific failure paths that lead to lock retention.