Description
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)
Published: 2026-10-18
Score: n/a
EPSS: n/a
KEV: No
Impact: Denial of Service – display timeout due to IRQ mismanagement
Action: Immediate Patch
AI Analysis

Impact

The vulnerability arises from a race condition in the AMD amdgpu driver that manages the GLOBAL_SYNC_STATUS register. The driver performs non‑atomic read/modify/write operations to enable or clear VUPDATE_NO_LOCK, resulting in a scenario where an IRQ handler can inadvertently clear the IRQ enable bit while another routine simultaneously acknowledges the interrupt. This flaw, indexed by CWE-362, can allow a privileged attacker to cause the driver to lose a vertical blank interrupt, potentially leading to a display timeout or loss of frame synchronization. While the flaw does not directly expose a remote code execution vector, it can degrade system stability and user experience.

Affected Systems

All Linux kernels that include the amdgpu display driver before the commit that atomizes these register accesses. This includes any Linux distributions running a kernel that has not been patched with commit 70de0a0216583a53c946155f8c8adedfdca6b4e7 or newer. The issue is specific to AMD GPUs that use the Global Sync registers for vblank handling; non‑AMD GPUs or kernels lacking the affected code are not impacted.

Risk and Exploitability

The CVSS score is not provided, and EPSS is not available. The flaw is listed as not being part of the CISA KEV catalog. Exploiting the race requires code execution in the kernel context, which typically limits attackers to local or privileged users rather than remote actors. Because the bug manifests as a timing race and the mitigation directly applies a spinlock, the likelihood of successful exploitation in the wild is considered low, but the impact of a successful exploit—loss of interrupt handling and potential display hang—can be significant for affected systems.

Generated by OpenCVE AI on October 18, 2026 at 19:02 UTC.

Remediation

No solution or workaround provided in the CVE record.

OpenCVE Recommended Actions

  • Update the Linux kernel to a version that includes the amdgpu commit 70de0a0216583a53c946155f8c8adedfdca6b4e7, which atomizes the GLOBAL_SYNC_STATUS register accesses.
  • Upgrade the AMD GPU driver to the latest kernel driver release that contains the spinlock‑based IRQ reset implementation.
  • For environments that cannot apply the patch immediately, disable or reduce the use of high‑refresh panels that rely heavily on VUPDATE_NO_LOCK, or configure the system to avoid enabling VUPDATE_NO_LOCK during peak display activity to mitigate the race.

Generated by OpenCVE AI on October 18, 2026 at 19:02 UTC.

Tracking

Sign in to view the affected projects.

Advisories

No advisories yet.

History

Sun, 18 Oct 2026 19:30:00 +0000

Type Values Removed Values Added
Weaknesses CWE-362

Sun, 18 Oct 2026 15:30:00 +0000

Type Values Removed Values Added
Description 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)
Title drm/amd/display: Atomize IRQ register read/modify/write ops
First Time appeared Linux
Linux linux Kernel
CPEs cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
Vendors & Products Linux
Linux linux Kernel
References

Subscriptions

Linux Linux Kernel
cve-icon MITRE

Status: PUBLISHED

Assigner: Linux

Published:

Updated: 2026-10-18T15:20:25.640Z

Reserved: 2026-09-25T10:25:14.362Z

Link: CVE-2026-98654

cve-icon Vulnrichment

No data.

cve-icon NVD

Status : Received

Published: 2026-10-18T16:17:18.690

Modified: 2026-10-18T16:17:18.690

Link: CVE-2026-98654

cve-icon Redhat

No data.

cve-icon OpenCVE Enrichment

Updated: 2026-10-18T19:15:14Z

Weaknesses
  • CWE-362

    Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition')