---
id: CVE-2026-98654
title: 'drm/amd/display: Atomize IRQ register read/modify/write ops'
summary: |-
  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 …
severity: none
vendor: Linux
product: Linux
affected:
  - >-
    Linux >= c87e6635d2db02c88ae8d09529362da672d34770 <
    63e19ef3ddab806c472748c825f4dc88dcd994e8
  - Linux 7.3-rc1
published: '2026-10-18'
updated: '2026-10-18'
sourceUpdated: '2026-10-18T15:20:25.640Z'
source: CVEORG
sourceUrl: 'https://www.cve.org/CVERecord?id=CVE-2026-98654'
references:
  - url: 'https://git.kernel.org/stable/c/63e19ef3ddab806c472748c825f4dc88dcd994e8'
tags:
  - cve.org
ingestedAt: '2026-10-18T15:45:12.225Z'
---

## Overview

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)

## Affected

- `Linux >= c87e6635d2db02c88ae8d09529362da672d34770 < 63e19ef3ddab806c472748c825f4dc88dcd994e8`
- `Linux 7.3-rc1`

## Remediation

Refer to the linked advisories for vendor-supplied fixes and affected version ranges.