Description

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)

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "8.8",
  "pubDate": "2026-09-16T11:16:46.267Z",
  "pubdate": "2026-09-16T11:16:46.267Z",
  "executiveSummary": "The Linux kernel's amdkfd driver suffers from an improper TLB invalidation vulnerability within the Micro Engine Scheduler (MES).\nThe vulnerability arises because the MES lacks an automatic heavy-weight TLB flush after unmapping GPU queues, diverging from the behavior of the Hardware Scheduler (HWS).\nThis race condition allows in-flight DMA descriptors to access memory addresses that have already been unmapped or freed, potentially leading to GPU page faults and system instability.\nThe impact includes GPU queue hangs and system-wide service disruption during Shared Virtual Memory (SVM) page migrations.\nThe vulnerability is primarily observed on hardware platforms like gfx1151 (Strix Point) when XNACK (eXternal Non-Access) mode 1 is enabled.\nExploitation requires the ability to trigger SVM page migrations or process evictions, effectively necessitating local execution access to the GPU device nodes.\nWhile this is primarily a stability and local denial-of-service vector, it highlights critical synchronization deficiencies in the memory management unit interface between the kernel and the MES.",
  "technicalDetails": "The vulnerability stems from a synchronization deficiency in the amdkfd driver when handling queue lifecycle events under the Micro Engine Scheduler (MES). In the GPU compute subsystem, mapping and unmapping memory ranges requires strict cache consistency to prevent stalled hardware agents from accessing stale memory translations.\nUnlike the Hardware Scheduler (HWS) implementation, which triggers an implicit heavy-weight TLB invalidation following queue unmapping, the MES assumes that the unmapping sequence is sufficient. This assumption is erroneous in the context of SVM (Shared Virtual Memory) page migrations. When a process undergoes queue eviction via 'evict_process_queues_cpsch' or debug/CRIU (Checkpoint/Restore In Userspace) suspension via 'suspend_queues', the memory pages associated with those queues may be unmapped or repurposed while the hardware DMA engines still possess active TLB entries pointing to the invalidated virtual memory.\nThe exploitation flow occurs as follows: 1) A process initiates an SVM page migration or eviction, prompting the kernel to unmap the queues associated with the GPU task. 2) The MES removes the queues without performing a global TLB invalidation. 3) Because the GPU DMA descriptors are still resident in hardware registers or internal buffers, they continue to reference the old memory mappings. 4) As the DMA engine attempts to read or write to these stale physical addresses, the memory management unit triggers a page fault or a hardware exception. 5) This results in an unrecoverable GPU queue hang, effectively rendering the compute unit unresponsive.\nThe vulnerable code paths are located in 'evict_process_queues_cpsch' and 'suspend_queues' within the amdkfd driver. By failing to invoke 'kfd_flush_tlb()' immediately after the unmapping phase, the driver allows a race condition to persist. The inclusion of a memory fence ('mem_fence') during suspension is required to ensure that all memory operations are retired before the invalidation takes effect. Failure to clear these TLB entries causes the hardware to behave unpredictably, leading to the observed failures in test suites such as 'KFDSVMRangeTest.MultiThreadMigrationTest'. This vulnerability affects kernel versions supporting the gfx1151 architecture, specifically when XNACK mode is active, as XNACK facilitates the page migration mechanisms that exacerbate the invalidation latency."
}