CVE-2026-98389
NoneCVSS
—
EPSS
0.2%
Published
Oct 14, 2026
CISA due date
—
Cloudanix analysis
A bug in the Linux driver for AMD graphics cards can cause computers to crash when the graphics processor resets itself.
- Exploitation
- Local Privilege
- Attacker needs
- Local User
- Complexity
- Moderate
- Impact
- Denial Of Service
- Component
- OS kernel
- Class
- Race Condition
- Remediation
- Upgrade
- Effort
- Medium
- Patch risk
- Low
What it actually does
Race condition in the amdgpu driver permits the gfx idle work handler to invoke switch_power_profile before GPU reset completion, allowing register access without releasing the reset semaphore and triggering assertion failures or kernel oops.
Why it matters to the business
AMD GPU-equipped systems risk instability or crashes during reset operations, interrupting graphics workloads, compute jobs, and requiring manual intervention or reboots.
How an attack unfolds
An attacker with local access induces GPU reset conditions while concurrently triggering power profile changes through the idle work path, hitting the unprotected window to force invalid register access and a resulting kernel crash.
How to fix it
Update the Linux kernel to a version containing the fix that skips gfx switch_power_profile during GPU reset (cherry-picked from upstream commit d93b1ff538ce9750c01e0dd0aa62575579c0fc08).
How to confirm the fix worked
Inspect kernel source or changelog for the skip logic in amdgpu_gfx_profile_idle_work_handler; reproduce GPU reset workloads and confirm absence of the associated call trace and register access errors.
Typical attack path
- Gain local code execution on a Linux system with AMD GPU
- Trigger or wait for a GPU reset event
- Invoke concurrent gfx idle work that calls switch_power_profile
- Exploit the missing semaphore check to perform unauthorized register access
- Cause kernel assertion failure and system instability
How to detect it
Review kernel logs (dmesg, journalctl) for the exact call trace involving amdgpu_gfx_profile_idle_work_handler, smu_switch_power_profile, and register access errors during GPU reset events.
- amdgpu_gfx_profile_idle_work_handler
- smu_switch_power_profile
- amdgpu_device_rreg
- CR2: 0000559ea133ead0
- ret_from_fork_asm
What your security team should do
- Prioritize kernel updates containing the amdgpu reset fix on all AMD GPU systems
- Test reset scenarios under load in non-production environments before broad deployment
- Monitor kernel logs for related oops or assertion patterns until patches are applied
The record
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)
Affected packages
| Ecosystem | Package | Introduced | Fixed |
|---|