CVE-2026-98389 in Linux
Summary
by MITRE • 10/15/2026
In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: skip gfx switch_power_profile during GPU reset
During resume from GPU reset, the gfx idle work may invoke switch_power_profile before the reset completes. This causes the following assert error because the register access occurs without first releasing the GPU reset semaphore:
[ 1576.768935] CR2: 0000559ea133ead0 CR3: 00000002e6c42000 CR4: 0000000000350ef0
[ 1576.768940] Call Trace:
[ 1576.768944] <TASK>
[ 1576.768953] amdgpu_device_rreg+0x21/0x50 [amdgpu]
[ 1576.769158] smu_msg_v1_send_msg+0x1a4/0x6e0 [amdgpu]
[ 1576.769437] smu_cmn_send_smc_msg_with_params_ext+0xba/0x120 [amdgpu]
[ 1576.769721] smu_cmn_send_smc_msg_with_param+0x33/0x40 [amdgpu]
[ 1576.769993] smu_v13_0_0_set_power_profile_mode+0x192/0x2b0 [amdgpu]
[ 1576.770267] smu_bump_power_profile_mode+0x5d/0x80 [amdgpu]
[ 1576.770538] smu_switch_power_profile+0xa4/0xf0 [amdgpu]
[ 1576.770839] amdgpu_dpm_switch_power_profile+0x6f/0x90 [amdgpu]
[ 1576.771210] amdgpu_gfx_profile_idle_work_handler+0xe9/0x130 [amdgpu]
[ 1576.771460] process_one_work+0x23e/0x6f0
[ 1576.771491] worker_thread+0x1c4/0x380
[ 1576.771506] kthread+0x10c/0x150
[ 1576.771512] ? __pfx_worker_thread+0x10/0x10
[ 1576.771518] ? __pfx_kthread+0x10/0x10
[ 1576.771530] ret_from_fork+0x314/0x390
[ 1576.771537] ? __pfx_kthread+0x10/0x10
[ 1576.771546] ret_from_fork_asm+0x1a/0x30
(cherry picked from commit d93b1ff538ce9750c01e0dd0aa62575579c0fc08)
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 10/15/2026
The Linux kernel's AMDGPU driver contains a race condition vulnerability that manifests during the GPU reset and subsequent resume process. This issue specifically affects systems utilizing Advanced Micro Devices graphics hardware where the display manager or power management subsystem attempts to adjust power profiles while the GPU is still in an unstable state following a hard reset. The core of the problem lies in the timing of work queue execution relative to the completion of the device reset sequence. When a GPU reset occurs, the driver enters a critical section protected by a semaphore designed to prevent concurrent access to hardware registers that are being reinitialized or are otherwise unavailable. However, during the resume phase after this reset, an idle monitoring worker thread may trigger a call to switch power profiles before the reset semaphore is fully released and the device state is considered stable.
This premature invocation of the power profile switching routine leads to unauthorized access to hardware registers that have not yet been properly initialized or are locked by the ongoing reset procedure. The kernel detects this illegal memory access attempt, resulting in a page fault as indicated by the provided call trace showing an invalid CR2 register value. The stack trace reveals that the error originates from amdgpu_device_rreg, which is called through a chain of functions including smu_msg_v1_send_msg and ultimately triggered by amdgpu_gfx_profile_idle_work_handler. This sequence demonstrates how background power management tasks can interfere with critical driver state transitions if synchronization primitives are not correctly ordered or checked during the reset recovery phase.
From a security perspective, this vulnerability is classified under CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization. The failure to ensure that shared resources such as GPU registers and internal device states are exclusively accessed during critical sections allows for race conditions that can lead to system instability or crashes. In the context of the MITRE ATT&CK framework, this scenario aligns with techniques related to resource manipulation where an attacker might potentially exploit timing differences in kernel operations to cause denial of service through repeated reset triggers and power profile changes. While primarily a stability issue rather than a direct privilege escalation vector, such race conditions can be leveraged in localized denial-of-service attacks against the graphical subsystem or system-wide if they trigger panic-inducing assertions.
The operational impact of this vulnerability includes kernel panics, system freezes, or unexpected reboots when users engage with graphics-intensive applications that cause GPU resets followed by immediate power state changes. This is particularly relevant for desktop environments and servers running workloads that stress the AMDGPU driver, such as gaming sessions, video rendering tasks, or machine learning computations involving GPU acceleration. The presence of assert errors in kernel logs indicates a clear violation of internal consistency checks within the driver code, signaling to system administrators that the software integrity has been compromised during runtime operations.
To mitigate this vulnerability, it is essential to apply the latest available updates for the Linux kernel and AMDGPU drivers provided by your distribution vendor or upstream source. The fix involves modifying the amdgpu driver logic to skip the switch_power_profile operation if a GPU reset is currently in progress or has not yet completed its synchronization phase. Administrators should ensure that their systems are patched against this specific race condition, which was addressed via cherry-picked commits from upstream kernel development branches. Regularly updating the graphics stack and monitoring system logs for similar assertion failures can help maintain stability and prevent potential denial-of-service scenarios arising from these timing-dependent flaws in hardware abstraction layers.