In the Linux kernel, the following vulnerability has been resolved:
drm/amdkfd: Add TLB flush after MES queue eviction/suspension
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)
CVSS Vector: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H
CVSS Score: 8.8
AV:L - 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:L - 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:L - 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:N - 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:C - 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:H - 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:H - 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:H - 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.
| Attack Vector |
Local |
Scope |
Changed |
| Attack Complexity |
Low |
Confidentiality Impact |
High |
| Privileges Required |
Low |
Integrity Impact |
High |
| User Interaction |
None |
Availability Impact |
High |
AV:L - 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:L - 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:L - 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:N - 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:C - 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:H - 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:H - 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:H - 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.
CVSS 3.1