CVE-2026-90064 in Linux
Summary
by MITRE • 09/17/2026
In the Linux kernel, the following vulnerability has been resolved:
drm/xe: Reject page faults from non-fault-mode scratch VMs
Having scratch enabled does not make a VM capable of handling recoverable page faults. Allowing scratch VMs through the ASID lookup also admits dma-fence mode VMs.
If such a VM faults on an already valid VMA, the handler reports success without fixing the fault, causing the GPU to retry indefinitely.
Only allow fault-mode VMs through the ASID lookup. Fault-mode VMs using scratch remain supported, while faults from 3D VMs are rejected.
(cherry picked from commit bfb24a06405b652d37831f3fb66b71d33a6605de)
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 09/17/2026
The Linux kernel's DRM Xe driver, which manages graphics processing units for Intel hardware, contains a logic flaw in its virtual memory address space identification and page fault handling mechanisms. The vulnerability arises from an incorrect assumption regarding the capabilities of different types of virtual machines within the GPU context. Specifically, the code previously allowed any virtual machine with scratch buffers enabled to proceed through the Address Space Identifier lookup process intended for handling recoverable page faults. This logic erroneously includes dma-fence mode virtual machines alongside standard fault-mode virtual machines. The core technical flaw is that having scratch memory enabled does not confer the ability to handle or resolve recoverable page faults, yet the driver permits these non-fault-capable contexts to engage with the fault resolution subsystem.
When a virtual machine that lacks proper fault-handling capabilities encounters a page fault on an already valid Virtual Memory Area, the current handler incorrectly reports success without actually resolving the underlying memory mapping issue. Because the fault is not fixed by the kernel's intervention, the graphics hardware continues to perceive the access as invalid and triggers another page fault event. This creates a recursive loop where the GPU repeatedly attempts to access the same unmapped or improperly mapped address space. The system fails to break this cycle because the driver accepts the virtual machine into the fault-handling path despite its inability to contribute to resolving the error, leading to an infinite retry sequence at the hardware level.
The operational impact of this vulnerability is severe for system stability and availability. An attacker who can trigger such a page fault condition on a susceptible virtual machine context can cause the graphics driver to hang indefinitely. This results in a denial of service where the GPU becomes unresponsive, potentially freezing the entire operating system or requiring a hard reset to recover. In cloud environments or multi-tenant systems utilizing Intel GPUs, this could allow one user's workload to disrupt services for others by exhausting hardware resources through infinite retry loops. The vulnerability effectively turns a standard memory access error into a persistent resource exhaustion vector that bypasses normal timeout mechanisms due to the driver's incorrect success reporting.
This issue is categorized under CWE-841 Improper Enforcement of Behavioral Workflow, as the software fails to enforce the correct sequence of operations required for safe page fault resolution. It also aligns with CWE-205 Observable Discrepancy in Correctly Computed Values because the handler reports a successful outcome while the underlying state remains unresolved. From an ATT&CK perspective, this vulnerability facilitates Denial of Service (T1499) by allowing local users to exhaust system resources through infinite loops. Mitigation strategies involve applying the upstream kernel patch that restricts ASID lookup access exclusively to fault-mode virtual machines. This ensures that only contexts with verified capability to handle recoverable page faults are permitted into the resolution logic, while still maintaining support for scratch-based operations within those valid fault modes. System administrators should update their Linux kernels to versions containing this fix to prevent GPU hangs and maintain service availability in graphics-intensive workloads.