GHSA-WFCC-C4GF-W2PC
Vulnerability from github – Published: 2026-10-18 18:31 – Updated: 2026-10-18 18:31In 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)
{
"affected": [],
"aliases": [
"CVE-2026-98654"
],
"database_specific": {
"cwe_ids": [],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-10-18T16:17:18Z",
"severity": null
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amd/display: Atomize IRQ register read/modify/write ops\n\n[Why]\n\nThe OTG_GLOBAL_SYNC_STATUS register controls various HW IRQ sources for\nthe output timing generator (OTG). VUPDATE_NO_LOCK is one of them.\n\nTo enable the IRQ, driver sets the VUPDATE_NO_LOCK_EN bit in the\nGLOBAL_SYNC_STATUS register.\n\nTo ack the IRQ after it fires, the driver sets the VUPDATE_NO_LOCK_CLEAR\nbit in the same GLOBAL_SYNC_STATUS register.\n\nThe bit sets are done through read/modify/write operations, which are\nnot atomic. Thus, the following race is possible:\n\n Thread A: IRQ handler:\n *HW IRQ fires*\n # IRQ disable\n val = read(GLOBAL_SYNC_STATUS)\n unset(val, VUPDATE_NO_LOCK_EN)\n write(val, GLOBAL_SYNC_STATUS)\n # ACK reads VUPDATE_NO_LOCK_EN unset\n val1 = read(GLOBAL_SYNC_STATUS)\n set(val1, VUPDATE_NO_LOCK_CLEAR)\n # IRQ enable\n val = read(GLOBAL_SYNC_STATUS)\n set(val, VUPDATE_NO_LOCK_EN)\n write(val, GLOBAL_SYNC_STATUS)\n # BAD! clears VUPDATE_NO_LOCK_EN\n write(val1, GLOBAL_SYNC_STATUS)\n\nRegarding the tagged Fixes: change, it appears the change made this race\nmore likely to occur. Since VUPDATE_NO_LOCK is now the sole IRQ source\nfor vblank handling, a single race on high refresh panels can lead to a\ntime out.\n\n[How]\n\nThe GLOBAL_SYNC_STATUS register is only one example, other IRQ control\nregisters also share the same scheme. On top of GLOBAL_SYNC_STATUS,\nlet\u0027s clean up those as well.\n\nTo keep things simple, Let\u0027s atomize the IRQ rmw ops via a single\ndriver-wide spinlock. Due to the small scope of this lock, it is\nunlikely to cause noticeable overhead on top of all the existing locking\nwithin the IRQ set/handle paths.\n\nSince DM is responsible for locking, wrap dc_interrupt_set/ack with the\nspinlock in the new amdgpu_dm_irq_set/ack functions. Migrate/drop all\nreferences in DM to dc_interrupt_set/ack to use amdgpu_dm_irq_set/ack\ninstead.\n\n(cherry picked from commit 70de0a0216583a53c946155f8c8adedfdca6b4e7)",
"id": "GHSA-wfcc-c4gf-w2pc",
"modified": "2026-10-18T18:31:58Z",
"published": "2026-10-18T18:31:58Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-98654"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/63e19ef3ddab806c472748c825f4dc88dcd994e8"
}
],
"schema_version": "1.4.0",
"severity": []
}
Drag nodes to arrange them. Double-click a related vulnerability to open it, or a source to visit its link. The Physics button on the left tunes the layout and the simulation; the legend at the bottom left hides or shows nodes by kind and by sighting type.
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
Vulnerability timeline
Sightings and recorded dates, grouped by day · UTC
Loading timeline…
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.