CVE-2026-98654

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

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)

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)