CVE-2026-80915 in Linux
Summary
by MITRE • 09/09/2026
In the Linux kernel, the following vulnerability has been resolved:
drm/xe: Fix DPT allocation paths.
Remove the fallback for VRAM to system memory, I tested it and that doesn't work at all, only a black screen with pipe fault errors were observed.
On systems with media GT, extra latency is added when accessing stolen memory when the GT is in MC6. Since we additionally aren't counting how much memory is used for stolen and we could in theory fill up the entire stolen area with DPT's, avoid using stolen and only use the default memory region.
Using stolen may also result in random system hangs under load.
(cherry picked from commit a196406a3831291598fe8e73245914f7acffdfe0)
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 09/09/2026
The Linux kernel driver for Intel Xe graphics, specifically within the Direct Page Table (DPT) allocation subsystem, contained critical implementation flaws that compromised system stability and display functionality. The vulnerability stems from an incorrect handling of memory regions during the initialization and management of page tables used by the GPU to map virtual addresses to physical frames. In systems utilizing media Graphics Technology units, particularly those with integrated graphics architectures where stolen memory is reserved for specific hardware functions, the driver previously attempted a fallback mechanism that allocated DPT structures in system memory when VRAM was unavailable or insufficient. This approach proved fundamentally flawed as it failed to account for the strict timing and access constraints associated with these specialized memory regions. The result of this misconfiguration manifests as severe graphical corruption, typically observed as a black screen accompanied by pipe fault errors reported by the display engine, indicating that the GPU cannot correctly interpret the page table entries located in the wrong memory space.
Beyond immediate display failures, the vulnerability introduces significant performance degradation and potential system instability due to improper interaction with stolen memory under specific power states. When the media GT enters MC6, a deep low-power state designed to conserve energy by gating clocks and reducing voltage, access latency to stolen memory increases substantially. The original code did not adequately account for this latency spike nor did it track the consumption of stolen memory resources relative to DPT allocations. Consequently, there is no upper bound preventing the driver from filling the entire reserved stolen area with page tables. This uncontrolled allocation can exhaust available hardware-reserved space, leading to resource conflicts that disrupt other critical GPU operations relying on that same memory region.
The operational impact of this vulnerability extends beyond mere display artifacts or performance penalties; it poses a risk of random system hangs under heavy load conditions. By allowing the DPT allocator to consume excessive amounts of stolen memory without proper bounds checking or latency-aware scheduling, the driver creates race conditions and resource starvation scenarios that can freeze the graphics subsystem entirely. These freezes often require a hard reset as they may prevent the kernel from recovering gracefully through standard error handling mechanisms. The issue is particularly prevalent on platforms where multiple display pipelines are active simultaneously or when high-resolution outputs demand larger page table structures, exacerbating the memory pressure on the limited stolen region.
To mitigate this vulnerability and restore system stability, the resolution involves removing the problematic fallback logic that targets VRAM to system memory transitions for DPT allocation. Instead of attempting complex cross-region allocations that lead to faults, the driver now restricts DPT usage exclusively to the default memory region, which is guaranteed to have consistent access characteristics and sufficient capacity managed by the kernel's standard memory management subsystem. This change eliminates the latency issues associated with MC6 state transitions for stolen memory and prevents the exhaustion of hardware-reserved resources. By adhering strictly to safe memory regions, the driver ensures predictable behavior across varying load conditions and power states, thereby preventing black screens, pipe faults, and system hangs.
From a security and standards perspective, this flaw aligns with CWE-401, which describes missing release of memory after effective lifetime, although in this context it manifests more as improper resource management leading to denial-of-service via system hang rather than traditional information leakage or privilege escalation. The behavior also relates to CWE-787 out-of-bounds write if the allocation logic allowed overwriting beyond reserved boundaries, though the primary impact here is functional instability. In terms of MITRE ATT&CK mapping, while this is not an exploitable attack vector for malicious actors in most standard deployments, it represents a weakness that could be leveraged in localized denial-of-service scenarios against systems relying on stable graphical output. The fix emphasizes robust resource accounting and adherence to hardware-specific memory constraints, reinforcing the principle of least privilege regarding memory region access within kernel drivers.