CVE-2026-98654 in Linux
Summary
by MITRE • 10/18/2026
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Atomize IRQ register read/modify/write ops
[Why]
The OTG_GLOBAL_SYNC_STATUS register controls various HW IRQ sources for the output timing generator (OTG). VUPDATE_NO_LOCK is one of them.
To enable the IRQ, driver sets the VUPDATE_NO_LOCK_EN bit in the GLOBAL_SYNC_STATUS register.
To ack the IRQ after it fires, the driver sets the VUPDATE_NO_LOCK_CLEAR bit in the same GLOBAL_SYNC_STATUS register.
The bit sets are done through read/modify/write operations, which are not atomic. Thus, the following race is possible:
Thread A: IRQ handler: *HW IRQ fires* # IRQ disable val = read(GLOBAL_SYNC_STATUS) unset(val, VUPDATE_NO_LOCK_EN) write(val, GLOBAL_SYNC_STATUS) # ACK reads VUPDATE_NO_LOCK_EN unset val1 = read(GLOBAL_SYNC_STATUS) set(val1, VUPDATE_NO_LOCK_CLEAR) # IRQ enable val = read(GLOBAL_SYNC_STATUS) set(val, VUPDATE_NO_LOCK_EN) write(val, GLOBAL_SYNC_STATUS) # BAD! clears VUPDATE_NO_LOCK_EN write(val1, GLOBAL_SYNC_STATUS)
Regarding the tagged Fixes: change, it appears the change made this race more likely to occur. Since VUPDATE_NO_LOCK is now the sole IRQ source for vblank handling, a single race on high refresh panels can lead to a time out.
[How]
The GLOBAL_SYNC_STATUS register is only one example, other IRQ control registers also share the same scheme. On top of GLOBAL_SYNC_STATUS, let's clean up those as well.
To keep things simple, Let's atomize the IRQ rmw ops via a single driver-wide spinlock. Due to the small scope of this lock, it is unlikely to cause noticeable overhead on top of all the existing locking within the IRQ set/handle paths.
Since DM is responsible for locking, wrap dc_interrupt_set/ack with the spinlock in the new amdgpu_dm_irq_set/ack functions. Migrate/drop all references in DM to dc_interrupt_set/ack to use amdgpu_dm_irq_set/ack instead.
(cherry picked from commit 70de0a0216583a53c946155f8c8adedfdca6b4e7)
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 10/19/2026
The vulnerability described involves a race condition within the Linux kernel's display manager for AMD graphics hardware, specifically affecting the Output Timing Generator (OTG) interrupt handling mechanisms. The core issue stems from non-atomic read-modify-write operations performed on hardware registers such as GLOBAL_SYNC_STATUS. This register controls various hardware interrupt sources, including VUPDATE_NO_LOCK, which is critical for vblank synchronization. To enable or acknowledge these interrupts, the driver must manipulate specific bits within this shared register using standard read-modify-write sequences that are not protected by atomic instructions at the hardware level.
The operational flaw arises when multiple execution contexts attempt to modify the same register simultaneously without proper serialization. In a typical scenario involving high refresh rate panels, Thread A may disable an interrupt by clearing its enable bit and subsequently re-enable it after performing other operations. Concurrently, the IRQ handler might acknowledge the interrupt by setting a clear bit. If the timing aligns unfavorably, the write operation from Thread A to re-enable the interrupt can overwrite the acknowledgment value written by the IRQ handler. This overwriting effectively clears the VUPDATE_NO_LOCK_EN bit prematurely or fails to set it correctly, leading to a state where the hardware does not generate expected interrupts or the driver misses them entirely.
This race condition has significant operational impacts on system stability and display performance. Because VUPDATE_NO_LOCK serves as the sole interrupt source for vblank handling in modern configurations, any failure in this mechanism can result in missed vertical blanking intervals. On high refresh rate displays, where timing windows are extremely tight, even a single instance of this race condition can lead to timeout errors within the driver stack. These timeouts manifest as display freezes, flickering, or complete loss of video output until the system recovers or is reset. The issue was exacerbated by recent changes that made VUPDATE_NO_LOCK the exclusive source for vblank handling, thereby increasing the frequency and criticality of this specific register access path.
From a technical classification perspective, this vulnerability aligns with CWE-362, which describes concurrent execution using shared resources with improper synchronization. It also relates to CWE-824, concerning access to a variable without locking, as the driver fails to serialize access to the hardware register during critical modification phases. In terms of MITRE ATT&CK mapping, this represents an internal race condition rather than an external attack vector, but it highlights weaknesses in resource management and synchronization primitives within kernel-space drivers that could potentially be leveraged for denial-of-service scenarios if triggered repeatedly by local userspace applications interacting with the display subsystem.
The resolution implemented involves atomizing these interrupt register read-modify-write operations through the introduction of a driver-wide spinlock. By wrapping the dc_interrupt_set and dc_interrupt_ack functions within new amdgpu_dm_irq_set and amdgpu_dm_irq_ack wrappers, all modifications to IRQ control registers are serialized under this single lock. This approach ensures that only one thread can modify the register state at any given time, eliminating the window for race conditions. The scope of the spinlock is kept small to minimize performance overhead, as it primarily protects short critical sections within interrupt handling paths where existing locking mechanisms were insufficient or absent.
Mitigation strategies focus on applying this kernel patch which updates the AMD display manager codebase. System administrators and developers should ensure that their Linux kernels include this fix by updating to a version containing commit 70de0a0216583a53c946155f8c8adedfdca6b4e7 or later. For environments running high refresh rate displays, verifying the integrity of interrupt handling is crucial. Regular kernel updates that incorporate synchronization fixes for hardware drivers are essential to maintain system stability and prevent display-related timeouts caused by these concurrency flaws.