Look up another CVE · open CVE-2026-89811 in the interactive tracker
CVE-2026-89811
drm/amdkfd: Add TLB flush after MES queue eviction/suspension
Published 2026-09-16 (33 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-89811 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 | vulnerable | 6.1.190-1 | No fix published anywhere yet, neither in Debian nor upstream for the series bookworm tracks. Watch the Debian tracker page for this CVE. Advisories for bookworm have historically landed a median of 23 days after publication. |
| Debian 13trixie | vulnerable | 6.12.113-1 | No fix published anywhere yet, neither in Debian nor upstream for the series trixie tracks. Watch the Debian tracker page for this CVE. Advisories for trixie have historically landed a median of 11 days after publication. |
| 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. |
The vulnerability
What the bug is
MES (Micro Engine Scheduler) does not perform heavy-weight TLB invalidation after unmapping queues, unlike HWS which does this automatically. This causes a race condition where in-flight DMA descriptors can access memory that has been unmapped, leading to page faults and GPU queue hangs during SVM page migration. The issue manifests as KFDSVMRangeTest.MultiThreadMigrationTest failures on gfx1151 (Strix Point) with XNACK mode 1 enabled - the GPU compute queue hangs with packets submitted but never consumed. Add kfd_flush_tlb() calls after MES queue removal in two locations: - evict_process_queues_cpsch(): after all queues removed during eviction - suspend_queues(): after debug/criu queue suspension (with mem_fence barrier) This ensures all in-flight memory accesses from unmapped queues are flushed before memory is freed or migrated. (cherry picked from commit f5c4f88e0f9c45a8fb9dfac0c1df726c95e41b77)
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/amdkfd/kfd_device_queue_manager.c
- What this is
- AMD KFDMAINTAINERS section matched on drivers/gpu/drm/amd/amdkfd/ · amd-gfx@lists.freedesktop.org · Supported
Show whether Debian builds this, per release
Not established. This site could not find the build rule for the affected file in the kernel trees Debian ships, so it has no answer about whether Debian compiles this code. Read that as unknown, never as absent.
- bookworm, trixie, forky, sid?
- ?
- not established - no Makefile entry for the affected file
Where a release above reads "not established", no build rule for the affected file was found in that release's kernel tree. That is a gap in this lookup, not a finding that the code is absent.
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
Signals
- Published
- 2026-09-16 (33 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.17%, higher than 5.5% 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 |
|---|---|---|
| 5.19 | 6.18.51 | e230c546ed93 |
| 5.19 | 7.2.5 | 6aae545c8708 |
| 5.19 | 7.3 | 94e25cb6ab7f |
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
- The bug is reached only via local /dev/kfd paths: AMDKFD_IOC_CREATE_QUEUE plus SVM/userptr activity (AMDKFD_IOC_SVM, munmap of USERPTR BOs) or KFD_IOC_DBG_TRAP_SUSPEND_QUEUES, which call evict_process_queues_cpsch()/suspend_queues(); there is no network, adjacent-wireless, or physical-device path.
- AC:LAttack complexity, low
- The attacker controls both sides of the race: they keep DMA in flight on their own MES compute/SDMA queues while concurrently forcing eviction or suspend via SVM migration, userptr MMU notifiers, TTM pressure, or self-debug suspend, matching the MultiThreadMigrationTest trigger with no victim timing or uncontrollable layout required.
- PR:LPrivileges required, low
- kfd_open() and the CREATE_QUEUE/SVM/DBG_TRAP ioctls perform no capability checks; a local unprivileged user with typical render/video-group access to /dev/kfd and /dev/dri/renderD* on desktops, ROCm nodes, and multi-tenant AMD GPU clouds is sufficient, not init-namespace root.
- UI:NUser interaction, none
- The attacker opens their own KFD and DRM render-node descriptors, submits compute work, and triggers queue eviction or suspend in that same process; no separate victim action such as mounting a filesystem or opening a crafted file is required.
- S:CScope, changed
- MES queue removal omits the heavyweight PASID TLB invalidation HWS performs, so in-flight GPU DMA can use stale GPUVM translations to physical pages after they are unmapped, freed, or migrated, bypassing the GPUVM/PASID DMA isolation boundary that is supposed to confine GPU access.
- C:HConfidentiality impact, high
- In-flight GPU DMA through stale GPUVM TLB entries can read physical pages after they leave the process mapping and are recycled to the page allocator, kernel, or another process, giving an arbitrary memory-disclosure primitive.
- I:HIntegrity impact, high
- The same stale translations allow GPU DMA writes into those recycled physical pages, enabling arbitrary memory corruption and control-flow hijacking through a device DMA write primitive.
- A:HAvailability impact, high
- The issue is documented to cause GPU page faults and compute-queue hangs (packets submitted but never consumed), which can stall the shared GPU and force amdgpu reset, denying compute service to all co-located workloads.