From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 117E638DC4C for ; Sun, 18 Oct 2026 15:37:50 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1792337871; cv=none; b=FVLr11hjVcv+gWjuR2OO+twNiRUzND0TwSn4O9VYhfWZC+cj5I8buc8cJsSrQGWU0AQJpBIjNCOXXeHB9bBjVeHsmTW1FLKif0JEwajjXba+oUNW3L3I3WhLU5Ih8HH3kdtC4EsQ0Iw37SGZt8DSOK9Um2T6JqqtUoDXG3bpK4Y= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1792337871; c=relaxed/simple; bh=hHcdG3DkfDCaxdw3jFGSfrfQIIuzv9lucOSbgHb0mLE=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=aZ4TEE3K3OhE7Bh1snvi/76aZZ3si0Q7Kd3CJJGqoqSsoQSy9rm7ROi3DKKe723B6hf1t9dp7OAeiNiYVSI1pGzC9rqI9HwRI/crgyIePu+OQ6aZtv71UWx70tcBj86XjHIIZGAwS9bBIzdaji9D/rOHZhjFFqA38m2um3BO9Pg= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b=Sct+nrY3; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b="Sct+nrY3" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2F50C1F000C4; Sun, 18 Oct 2026 15:37:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linuxfoundation.org; s=korg; t=1792337870; bh=sY1vbtW2RqbxwFokQOTVZs7jzP2MNq06H/o9Bl/6c8U=; h=From:To:Cc:Subject:Date:Reply-To; b=Sct+nrY3RpUF7q751JhA8vTxPWewG/yImWIvzCEZr5arPpR2IlGnnxv7NGRYpvTJJ 1AuCgU/4vveu5lEt7T7NqQnb9S01S6C3bqX1lLPeGy3jczlOlBFepAbaFZyz3AKJHO WTn6087SKSsuoVW50BonQrfF3mvSTRKVtTJwyRSM= From: Greg Kroah-Hartman To: linux-cve-announce@vger.kernel.org Cc: Greg Kroah-Hartman Subject: CVE-2026-98654: drm/amd/display: Atomize IRQ register read/modify/write ops Date: Sun, 18 Oct 2026 17:18:38 +0200 Message-ID: <2026101848-CVE-2026-98654-d983@gregkh> X-Mailer: git-send-email 2.56.0 Reply-To: , Precedence: bulk X-Mailing-List: linux-cve-announce@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-Developer-Signature: v=1; a=openpgp-sha256; l=4213; i=gregkh@linuxfoundation.org; h=from:subject:message-id; bh=rh3or74SC1eDe8qQt/0dRuV5W5wwyPFI6qHpvhroyCk=; b=owGbwMvMwCRo6H6F97bub03G02pJDFlXHi358X2Jz60Jx5ovVfxk3pXj+bztxKaMw5qLeK5FT 7y0uffG8o5YFgZBJgZZMUWWL9t4ju6vOKToZWh7GmYOKxPIEAYuTgGYyLyPDAuO8xRtjzm98m2d vkF4x8ppe6e1MXQyzE8uWHNsy478Z58/ND6zFbsR4N/+mhkA X-Developer-Key: i=gregkh@linuxfoundation.org; a=openpgp; fpr=F4B60CC5BF78C2214A313DCB3147D40DDB2DFB29 Content-Transfer-Encoding: 8bit From: Greg Kroah-Hartman 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) The Linux kernel CVE team has assigned CVE-2026-98654 to this issue. Affected and fixed versions =========================== Issue introduced in 7.3-rc1 with commit c87e6635d2db02c88ae8d09529362da672d34770 and fixed in 7.3-rc4 with commit 63e19ef3ddab806c472748c825f4dc88dcd994e8 Please see https://www.kernel.org for a full list of currently supported kernel versions by the kernel community. Unaffected versions might change over time as fixes are backported to older supported kernel versions. The official CVE entry at https://cve.org/CVERecord/?id=CVE-2026-98654 will be updated if fixes are backported, please check that for the most up to date information about this issue. Affected files ============== The file(s) affected by this issue are: drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crtc.c drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_irq.c drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_irq.h drivers/gpu/drm/amd/display/amdgpu_dm/tests/amdgpu_dm_crtc_test.c drivers/gpu/drm/amd/display/amdgpu_dm/tests/amdgpu_dm_helpers_test.c drivers/gpu/drm/amd/display/amdgpu_dm/tests/amdgpu_dm_irq_test.c Mitigation ========== The Linux kernel CVE team recommends that you update to the latest stable kernel version for this, and many other bugfixes. Individual changes are never tested alone, but rather are part of a larger kernel release. Cherry-picking individual commits is not recommended or supported by the Linux kernel community at all. If however, updating to the latest release is impossible, the individual changes to resolve this issue can be found at these commits: https://git.kernel.org/stable/c/63e19ef3ddab806c472748c825f4dc88dcd994e8