CVE-2026-99090 in Linux
Summary
by MITRE • 10/26/2026
In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: serialize vblank counter reads against GPU reset
The vblank counter callback reads display registers and scanout position without holding reset_domain->sem. During GPU recovery, display commit work can call the callback while reset owns the semaphore for writing. The hardware access then triggers the lockdep_assert_held() in amdgpu_device_skip_hw_access() and sets TAINT_WARN when lockdep is enabled.
Try to acquire the reset semaphore for reading before accessing the hardware, and hold it across the counter and scanout-position reads. If reset is already in progress, return DRM's cached software vblank count instead. This avoids blocking behind reset and avoids accessing display hardware while it is being reset.
The cached count is less accurate than the hardware count, but is used only when reset prevents a safe hardware read. This addresses the reset-time warning from this vblank path; it does not suppress or fix unrelated lockdep warnings.
(cherry picked from commit 51a4359f7431a4be5e42803c8bdaf7e0e5be2934)
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 10/26/2026
The Linux kernel's DRM subsystem for AMD GPU drivers contains a concurrency flaw within the vertical blanking counter callback mechanism that can lead to race conditions during hardware reset operations. The core issue stems from the fact that the vblank counter callback reads display registers and determines the scanout position without acquiring the necessary synchronization primitives, specifically the reset_domain semaphore. This lack of locking creates a window where concurrent execution paths may interfere with each other, particularly when the GPU is undergoing recovery or reset procedures.
During a GPU reset sequence, the system holds the reset domain semaphore to ensure exclusive access for writing and configuration changes required to restore hardware state. However, display commit work can simultaneously invoke the vblank counter callback, which attempts to read from these same hardware registers without holding any corresponding lock. This asynchronous access violates kernel locking expectations and triggers a warning within the amdgpu_device_skip_hw_access function when lockdep is enabled. The presence of this warning indicates that the code path accessed hardware resources while they were being modified by another context, potentially leading to undefined behavior or system instability if not for the protective warnings provided by debug tools.
The operational impact of this vulnerability includes kernel taint warnings and potential data corruption or incorrect display state reporting during high-load scenarios where GPU resets occur frequently. While the immediate symptom is often a logged warning rather than a catastrophic failure, the underlying race condition represents a significant integrity risk. It compromises the reliability of the graphics subsystem by allowing unsynchronized reads against hardware that may be in an indeterminate state due to ongoing reset operations. This can result in inaccurate frame timing information being passed up to user-space applications or display managers, potentially causing visual artifacts or synchronization issues in rendering pipelines.
To mitigate this vulnerability, the fix implements a strategy of serializing access by attempting to acquire the reset semaphore for reading before performing any hardware accesses related to vblank counting and scanout position determination. If the semaphore cannot be acquired because a reset is already in progress, the driver returns a cached software-based vblank count instead of accessing the potentially unstable hardware registers. This approach ensures that no unsafe reads occur during critical maintenance windows while maintaining system responsiveness by avoiding blocking indefinitely behind long-running reset operations. The trade-off involves accepting slightly less accurate timing data when resets are active, which is deemed acceptable given the priority of preventing race conditions and kernel warnings over precise microsecond-level accuracy in those specific edge cases.
From a vulnerability classification perspective, this issue aligns with CWE-362, Concurrent Execution using Shared Resource with Improper Synchronization, as it involves multiple execution contexts accessing shared hardware resources without proper locking mechanisms. In terms of the MITRE ATT&CK framework for enterprise security, while this is primarily an internal stability and reliability flaw rather than a direct exploitation vector for external attackers, it relates to techniques involving resource manipulation that could theoretically be leveraged in denial-of-service scenarios if triggered repeatedly by malicious user-space processes designed to induce GPU resets. The resolution reinforces the principle of least privilege regarding hardware access contexts and ensures that state transitions during reset are handled with appropriate mutual exclusion guarantees.