CVE-2026-98654

Source
https://cve.org/CVERecord?id=CVE-2026-98654
Import Source
https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2026-98654.json
JSON Data
https://api.osv.dev/v1/vulns/CVE-2026-98654
Downstream
Published
2026-10-18T15:20:25Z
Modified
2026-10-19T02:47:02Z
Summary
drm/amd/display: Atomize IRQ register read/modify/write ops
Details

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)

Database specific
{
    "cna_assigner":  "Linux",
    "osv_generated_from":  "https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/98xxx/CVE-2026-98654.json"
}
References

Affected packages

Git / git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git

Affected ranges

Type
GIT
Repo
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Events
Introduced
c87e6635d2db02c88ae8d09529362da672d34770
Fixed
63e19ef3ddab806c472748c825f4dc88dcd994e8

Database specific

source
"https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2026-98654.json"