CVE-2026-90286
High · 8.8CVSS
8.8
EPSS
0.2%
Published
Sep 17, 2026
CISA due date
—
Cloudanix analysis
A bug in how graphics hardware processes tasks on certain AMD chips could let someone already on the computer take over the whole machine.
- Exploitation
- Local Privilege
- Attacker needs
- Low Privilege
- Complexity
- Low
- Impact
- Full Compromise
- Component
- OS kernel
- Class
- Race Condition
- Remediation
- Upgrade
- Effort
- Medium
- Patch risk
- Low
What it actually does
Race condition in amdgpu GFX6 compute queue handling allows PFP to begin executing a new submission while ME is still processing the prior one due to missing PFP_SYNC_ME and incorrect fence waits on compute rings that share the CP path with graphics.
Why it matters to the business
Local attackers can achieve kernel-level code execution or memory corruption on affected AMD GPU systems, leading to full host compromise, data theft, or ransomware deployment with high urgency given the 37-day window since disclosure.
How an attack unfolds
An attacker with local access submits crafted GPU command buffers to compute queues; the missing PFP synchronization permits overlapping execution of register writes and fence operations, allowing the attacker to bypass isolation and inject malicious commands that escalate to kernel privileges.
How to fix it
Update to a Linux kernel containing the referenced amdgpu/gfx6 PFP fix on compute queues; rebuild and reboot systems using affected AMD GPUs; apply vendor backports for distribution kernels released after 2026-09-17.
How to confirm the fix worked
Confirm kernel version includes the PFP register write and PFP_SYNC_ME changes for compute queues; run amdgpu-specific regression tests exercising concurrent graphics and compute submissions; verify no fallback to ME-only fencing remains in dmesg or driver logs.
Typical attack path
- Obtain local unprivileged shell on Linux system with AMD GFX6 GPU
- Map GPU rings and issue command submissions to compute queues via userspace driver
- Trigger concurrent submissions to race PFP against ME execution
- Exploit overlapping fence handling to corrupt kernel state or execute arbitrary commands
- Escalate to full root access or kernel code execution
How to detect it
Review kernel logs and audit trails for unusual amdgpu compute ring submissions or fence synchronization warnings; correlate with process activity creating GPU contexts on GFX6 hardware; no public exploitation artifacts known at this time.
What your security team should do
- Prioritize kernel upgrades on all GFX6 AMD systems within the next 7 days
- Restrict untrusted local users from direct GPU access via cgroups or driver blacklisting until patched
- Monitor for post-patch anomalies in GPU command submission latency
- Include this race condition class in future kernel fuzzing campaigns
The record
In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/gfx6: Use PFP on the compute queues too On GFX6, the compute rings use the same CP path as the graphics ring. The only difference is that they don't support draw commands. (As opposed to GFX7 and newer which have a separate command parser that is called MEC for compute queues.) This means that we have to take into consideration that the PFP also exists on compute queues on GFX6: Use PFP for register writes on both graphics and compute queues. In the pipeline sync, use the PFP to wait for the previous fence (and not the ME) to prevent the PFP from starting to execute the next submission while the ME is still in the previous submission. After a VM flush, emit PFP_SYNC_ME on compute queues as well.
Affected packages
| Ecosystem | Package | Introduced | Fixed |
|---|