Linux Kernel EUVD-2026-80411

Requires local access to an affected AMD GPU/APU with KFD/ROCm compute enabled - specifically reproduced on gfx1151 (Strix Point) with XNACK mode 1 (page-fault-based SVM) active. The bug only triggers during MES-scheduled queue eviction (evict_process_queues_cpsch) or debug/CRIU queue suspension (suspend_queues) concurrent with SVM page migration, so it needs a system using the MES firmware scheduler path (not the HWS path, which flushes automatically) and a workload that both migrates memory and evicts/suspends queues. Limiting factors: it is a timing-sensitive race (not deterministic), needs an unprivileged-but-GPU-authorized local user, applies to a narrow set of AMD hardware/driver configurations, and does not affect systems without KFD SVM in use.

This is a local, race-condition-dependent memory-safety bug in the AMD KFD (amdkfd) driver's MES scheduler path, not a remotely exploitable flaw. The vendor CVSS vector (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H = 8.8) is materially over-scored on two axes: AC:L understates a genuine race condition (in-flight DMA descriptors vs. TLB invalidation during SVM page migration) that requires precise timing and a specific trigger, and S:C (scope change) is questionable - the fault is contained within kernel/GPU-managed memory and the driver, not a demonstrably separate security authority. The described real-world impact is dominated by GPU compute queue hangs and page faults (availability), with confidentiality/integrity exposure arising only from stale DMA reaching freed or migrated pages. No EPSS score, no CISA KEV listing, and no public POC are present in the input; exploitation status is therefore 'no public exploit identified at time of analysis.' The reproducer named (KFDSVMRangeTest.MultiThreadMigrationTest on gfx1151 with XNACK mode 1) is a kernel selftest, not a weaponized exploit. CONFLICT TO VERIFY: the 'Information Disclosure' tag conflicts with the description and the vendor's own C:H/I:H/A:H vector - this is full-triad memory corruption plus denial-of-service, not an info-disclosure-only issue. Net: real but low-priority for most fleets given the local vector, race complexity, and narrow hardware/config preconditions.

A local user with GPU compute access on an affected AMD APU (e.g., gfx1151 / Strix Point) runs HSA/ROCm SVM workloads with XNACK mode 1 and drives concurrent memory migration while queues are evicted or suspended, so MES unmaps queues without a heavy-weight TLB flush. In-flight DMA descriptors then read or write pages that have been freed or migrated, producing GPU queue hangs and page faults and potentially corrupting or leaking kernel-managed memory. No public exploit code is identified; the only demonstrated trigger is the kernel's own multi-thread migration selftest.