Look up another CVE · open CVE-2026-90286 in the interactive tracker
CVE-2026-90286
drm/amdgpu/gfx6: Use PFP on the compute queues too
Published 2026-09-17 (31 days ago) by the Linux kernel CNA. Subsystem drivers/gpu. Debian urgency: not yet assigned.
What to do, per Debian release
Debian's own status for CVE-2026-90286 in every release this site tracks, and what each one means in practice. Every status below is the one the Debian Security Team publishes for this CVE. source
| Release | Status | Version | What this means |
|---|---|---|---|
| Debian 12bookworm | fixedDLA-4841-1 · 2026-10-17 · text | 6.1.190-1 | Update the kernel and reboot. DLA-4841-1 shipped the fix on 2026-10-17, in 6.1.190-1. A running kernel keeps the old code until the machine restarts. |
| Debian 13trixie | fixedDSA-6528-1 · 2026-09-29 · text | 6.12.111-1 | Update the kernel and reboot. DSA-6528-1 shipped the fix on 2026-09-29, in 6.12.111-1. A running kernel keeps the old code until the machine restarts. |
| Debian 14forky | fixed | 7.2.6-1 | Update the kernel and reboot. Fixed in 7.2.6-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 7.2.6-1 | Update the kernel and reboot. Fixed in 7.2.6-1. A running kernel keeps the old code until the machine restarts. |
| Debian 12bookworm · linux-6.12 | fixedDLA-4817-1 · 2026-10-04 · text | 6.12.111-1~deb12u1 | Update the kernel and reboot. DLA-4817-1 shipped the fix on 2026-10-04, in 6.12.111-1~deb12u1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
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.
Where it lives
The fix touches these files. If the subsystem is one you do not use, the practical exposure is lower, though the package is still the vulnerable one.
drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c
- What this is
- RADEON and AMDGPU DRM DRIVERSMAINTAINERS section matched on drivers/gpu/drm/amd/ · amd-gfx@lists.freedesktop.org · Supported
- Kernel module
- amdgpu
Check it on the machine
grep -wE 'CONFIG_DRM_AMDGPU|CONFIG_DRM_AMDGPU_SI' /boot/config-$(uname -r)Reads the booted kernel's own configuration, on the machine and nowhere else. =y is built in, =m is a module, and an is not set line means the code is not there.
lsmod | grep -w amdgpuPrints a line if that module is loaded right now, and nothing if it is not. One that is not loaded can still be loaded later by anything that needs it.
Show whether Debian builds this, per release
Debian builds this, but not on every flavour. At least one release below builds the code on some of its kernel flavours and not on others, so the answer depends on the architecture and flavour installed.
- bookwormMnot built on amd64/cloud-amd64, arm64/cloud-arm64, armhf/armmp, armhf/armmp-lpae, armhf/rt/armmp
- trixieMnot built on amd64/cloud-amd64, arm64/cloud-arm64, armel/rpi, armhf/armmp, armhf/armmp-lpae, armhf/rt/armmp, s390x/s390x
- forky, sidMnot built on amd64/cloud-amd64, arm64/cloud-arm64, s390x/s390x
- bookworm · linux-6.12Mnot built on amd64/cloud-amd64, arm64/cloud-arm64, armhf/armmp, armhf/armmp-lpae, armhf/rt/armmp
- M
- a module where it is built at all; some flavours do not build it
- Build switches
- CONFIG_DRM_AMDGPU, CONFIG_DRM_AMDGPU_SI
- Reads as
- all on means the file is compiled; any one off means it is not.
From the configuration Debian publishes for every kernel flavour it builds. It covers only the architectures Debian ships a linux-config package for, and nothing about a kernel you built yourself. Debian's own status above stays authoritative about the source package.MAINTAINERS kbuild Makefiles Debian linux-config packages
Signals
- Published
- 2026-09-17 (31 days ago)source
- CVSS
- 8.8 high
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:Hsource recompute it - Attack vector
- local (AV:L)source
- EPSS
- 0.18%, higher than 6.6% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- not yet assignedsource
- Subsystem
- drivers/gpu
Upstream fixes
The versions the CNA records as introducing and fixing this, and the commit for each. source
| Introduced | Fixed in | Commit |
|---|---|---|
| 4.9 | 5.10.270 | f37211b9c014 |
| 4.9 | 5.15.221 | 2aa869c6b23e |
| 4.9 | 6.1.188 | fbabc39b4f0f |
| 4.9 | 6.6.157 | b5d1d3e4519d |
| 4.9 | 6.12.110 | e1d3018e3621 |
| 4.9 | 6.18.52 | 8d752f1bb73f |
| 4.9 | 7.2.6 | e399e9d7e291 |
| 4.9 | 7.3 | 60f20946cd31 |
Debian advisories
| Advisory | Date | Shipped to | Debian |
|---|---|---|---|
| DLA-4841-1 | 2026-10-17 | bookworm 6.1.190-1 | tracker |
| DLA-4817-1 | 2026-10-04 | bookworm 6.12.111-1~deb12u1 | tracker |
| DSA-6528-1 | 2026-09-29 | trixie 6.12.111-1 | tracker |
Why the CNA scored it this way
Quoted from the kernel CNA's own scoring file, word for word. A highlighted metric carries the most severe value CVSS v3.1 defines for it, which is what pushes the score up. source
- AV:LAttack vector, local
- gfx_v6_0_ring_emit_pipeline_sync/emit_vm_flush/emit_wreg run from local DRM_IOCTL_AMDGPU_CS (amdgpu_cs_ioctl → amdgpu_cs_submit → amdgpu_job_run → amdgpu_ib_schedule → amdgpu_vm_flush) on GFX6 CP_RB1/RB2 compute rings; the trigger is the caller’s own CS IB on /dev/dri/renderD*, not a remote protocol message.
- AC:LAttack complexity, low
- On GFX6, amdgpu_vm_check_compute_bug sets has_compute_vm_bug so every compute job with a VMID emits WAIT_REG_MEM via gfx_v6_0_ring_emit_pipeline_sync, and gmc_v6_0_emit_flush_gpu_tlb uses emit_wreg; usepfp was 0 so PFP never waits. The attacker submits sequential AMDGPU_HW_IP_COMPUTE IBs and PFP prefetching ahead of ME is normal hardware behavior, not a victim-timed race.
- PR:LPrivileges required, low
- AMDGPU_CS is registered DRM_AUTH|DRM_RENDER_ALLOW in amdgpu_ioctls_kms; drm_ioctl_permit() does no capable() check for that path, so any unprivileged local user who can open the render node (typical render/video group) can create a ctx and submit compute IBs without init-namespace root.
- UI:NUser interaction, none
- The attacker opens their own /dev/dri/renderD* fd, issues DRM_IOCTL_AMDGPU_CTX/GEM_VA and DRM_IOCTL_AMDGPU_CS with ip_type=AMDGPU_HW_IP_COMPUTE, and trips gfx_v6_0_ring_emit_vm_flush themselves; no other user must mount, open, or interact with a GPU context.
- S:CScope, changed
- Without PFP_SYNC_ME after gfx_v6_0_ring_emit_vm_flush, and with WRITE_DATA of mmVM_CONTEXT*_PAGE_TABLE_BASE_ADDR/mmVM_INVALIDATE_REQUEST issued on ME, the PFP/CUs can DMA using stale GPUVM TLB entries after a VMID switch or unmap, crossing the GPUVM DMA isolation boundary that is supposed to confine each VMID to its current page tables.
- C:HConfidentiality impact, high
- PACKET3_INDIRECT_BUFFER in gfx_v6_0_ring_emit_ib is fetched by PFP through GPUVM; if that fetch and the subsequent dispatch run before ME finishes gmc_v6_0_emit_flush_gpu_tlb, loads hit leftover translations to pages already reused by another process or the kernel, which is an arbitrary physical-memory read via GPU DMA.
- I:HIntegrity impact, high
- The same stale VM_CONTEXT PTEs let compute shaders and CP packets store through GPU VAs whose physical pages were remapped after GEM_VA unmap or VMID reuse, giving a GPU DMA write into recycled host pages and control-flow hijack via hostile packet bytes the PFP fetched from the wrong address.
- A:HAvailability impact, high
- Invalid PFP reads of IB contents through a not-yet-invalidated TLB feed garbage into the SI CP (the commit’s stated failure mode), causing VM faults, compute-ring hangs on CP_RB1/RB2, and amdgpu GPU reset that takes down the shared GFX6 device.