UBUNTU-CVE-2026-99090: Medium severity vulnerability
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 resetdomain->sem. During GPU recovery, display commit work can call the callback while reset owns the semaphore for writing. The hardware access then triggers the lockdepassertheld() in amdgpudeviceskiphwaccess() and sets TAINTWARN 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)
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
Linux kernel drm/amdgputo a version that resolves this vulnerability.Patch 51a4359f7431a4be5e42803c8bdaf7e0e5be2934
Frequently Asked Questions
Which systems are exposed to this issue?
Systems using the Linux kernel AMDGPU DRM driver are relevant. The warning occurs when the vblank counter path accesses display hardware while a GPU reset is in progress.
What conditions are required to trigger it?
A GPU recovery/reset must overlap with display commit work that reads the vblank counter or scanout position. With lockdep enabled, the unsafe hardware access triggers a lockdep assertion and sets TAINT_WARN.
What happens when a reset is already underway after the fix?
The driver returns DRM's cached software vblank count rather than reading display hardware. This avoids waiting for the reset and prevents hardware access during the reset, although the returned count may be less accurate.