Linux Kernel up to 7.3-rc1/7.3-rc3 IRQ drm/amd/display amdgpu_dm_irq_set/ack race condition

Summaryinfo

A vulnerability marked as very critical has been reported in Linux Kernel up to 7.3-rc1/7.3-rc3. This affects the function amdgpu_dm_irq_set/ack of the file drm/amd/display of the component IRQ Handler. The manipulation leads to race condition. This vulnerability is documented as CVE-2026-98654. The attack can be initiated remotely. There is not any exploit available. It is suggested to upgrade the affected component.

Detailsinfo

A vulnerability, which was classified as very critical, has been found in Linux Kernel up to 7.3-rc1/7.3-rc3. This issue affects the function amdgpu_dm_irq_set/ack of the file drm/amd/display of the component IRQ Handler. The manipulation with an unknown input leads to a race condition vulnerability. Using CWE to declare the problem leads to CWE-362. The product contains a code sequence that can run concurrently with other code, and the code sequence requires temporary, exclusive access to a shared resource, but a timing window exists in which the shared resource can be modified by another code sequence that is operating concurrently. Impacted is confidentiality, integrity, and availability. The summary by CVE is:

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)

It is possible to read the advisory at git.kernel.org. The identification of this vulnerability is CVE-2026-98654 since 09/25/2026. The exploitation is known to be easy. The attack may be initiated remotely. Technical details of the vulnerability are known, but there is no available exploit. The pricing for an exploit might be around USD $0-$5k at the moment (estimation calculated on 10/18/2026).

Upgrading to version 7.3-rc1 or 7.3-rc4 eliminates this vulnerability. Applying the patch 63e19ef3ddab806c472748c825f4dc88dcd994e8 is able to eliminate this problem. The best possible mitigation is suggested to be upgrading to the latest version.

Be aware that VulDB is the high quality source for vulnerability data.

Productinfo

Type

• Operating System

Vendor

• Linux

Name

• Kernel

Version

• 7.3-rc1
• 7.3-rc2
• 7.3-rc3

License

• open-source

Website

• Vendor: https://www.kernel.org/

CPE 2.3info

• 🔒
• 🔒
• 🔒

CPE 2.2info

• 🔒
• 🔒
• 🔒

CVSSv4info

CVSSv3info

CVSSv2info

Exploitinginfo

Threat Intelligenceinfo

Countermeasuresinfo

Timelineinfo

Sourcesinfo

Entryinfo

Be aware that VulDB is the high quality source for vulnerability data.

Discussion