CVE-2026-90047 in Linux
Summary
by MITRE • 09/16/2026
In the Linux kernel, the following vulnerability has been resolved:
drm/xe: Don't hand out the flat CCS storage as usable VRAM
get_flat_ccs_offset() reads the base of the flat CCS storage from the hardware, scales it by the number of enabled L3 nodes, and rounds the result up to 128K. Everything below that offset is then handed to the VRAM allocator as usable memory.
Rounding a limit that means "usable memory ends here" upwards publishes whatever lies between the real base and the rounded one as free memory, and that memory belongs to the compression hardware. The scaled value has no reason to be 128K aligned, and on a Battlemage G21 with 16 GiB it is not:
flat CCS base: raw 0x3fafff800, rounded 0x3fb000000
so the last 2 KiB of page 0x3fafff000 is CCS storage, in the allocator's pool. Whatever is allocated there gets that tail overwritten by the compression hardware, which needs no page-table entry, no buffer object and no GPU submission to do it, and does it before userspace exists.
On this machine a Mesa VM's level-3 page table landed on that page on every cold boot. It lost the entry covering the compositor's batch-buffer heap, so the compositor's first submission faulted fetching its batch and gdm restarted it forever: a black screen on an otherwise working machine. Restarting gdm cleared it because the next VM's page tables were allocated somewhere else.
Round down instead, to the page size the allocator works in. On this machine that excludes exactly one page.
Reading the reserved page afterwards shows what had been writing it:
[369] 0xcccc000000000000
[371] 0xcc77000000000000
[373] 0xcccc000000000000
[375] 0xcc77000000000000
compression metadata, two bytes per sixteen, sitting where the driver used to hand out memory.
The assertion that should have caught this compares the offset against GSMBASE - ccs_size for equality. That value is 128K aligned, so it agrees with the rounded-up offset precisely when the base is not aligned - the check cannot fail in the case it exists to catch, and is compiled out unless CONFIG_DRM_XE_DEBUG is set. Replace it with one that can fail: CCS storage must not run into GSM.
[ And this was a debug session from hell, enormously helped by an AI
doing much of the grunt-work.
I'd like to call it my tireless helper, but the AI several times stated flat out that this was impossible and unsolvable and that we should just write a report about it.
I suspect those things have been trained by people who may not be quite as stubborn as I am.
But while the AI was ready to give up several times, it did keep adding debug code and analyzing it faithfully when I pushed. So credit where credit is due and I let the AI write the commit message above.
This is basically a one-liner fixing a bogus "round_up()" to a "round_down()", but there were 24 patches adding more and more debug information to this, and 18 kernel boot to finally narrow it down to this. - Linus ]
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 09/16/2026
The Linux kernel driver for Intel Xe graphics contains a critical memory management flaw in the handling of flat Compressed Color Surface (CCS) storage regions on Battlemage G21 hardware and similar architectures with integrated compression capabilities. The vulnerability originates from the get_flat_ccs_offset function, which is responsible for determining the boundaries between usable Video RAM (VRAM) and reserved hardware-managed memory used by the GPU's compression engine. Specifically, this function reads a base offset from hardware registers, scales it based on enabled L3 cache nodes, and then applies an upward rounding operation to align the result to 128 kilobytes before reporting the end of usable VRAM to the system allocator. This architectural decision introduces a boundary condition error where memory that belongs exclusively to the compression hardware is inadvertently exposed as free, allocatable space to the operating system's virtual memory manager.
The technical root cause lies in the misuse of rounding logic for memory boundaries. When calculating the limit of available memory, rounding up expands the reported range into reserved territory rather than contracting it toward safe limits. On systems such as the Battlemage G21 with 16 GiB of VRAM, this miscalculation results in approximately two kilobytes of page data being incorrectly classified as free. Consequently, when the kernel's memory allocator assigns these pages to user-space processes or internal structures like Mesa virtual machine page tables, it overwrites critical compression metadata maintained by the hardware. This corruption occurs without any explicit GPU submission or buffer object creation because the compression engine operates autonomously at a low level, continuously writing its state information into physical addresses that are now mapped as writable memory for general-purpose use.
The operational impact of this vulnerability is severe and manifests primarily through system instability and graphical interface failure. In observed instances on affected hardware, the corruption of page table entries leads to immediate faults during GPU command submission. A specific scenario involves the Graphics Device Manager (GDM) compositor losing access to its batch-buffer heap due to overwritten page table mappings. This results in a black screen as the display server repeatedly crashes and restarts in an infinite loop, rendering the system unusable despite other subsystems functioning correctly. The issue is particularly insidious because it can occur during cold boots when initial memory allocations happen unpredictably, making it difficult for users to reproduce consistently without specific boot conditions or workload patterns that trigger allocation of the corrupted pages early in the initialization sequence.
Mitigation strategies involve correcting the rounding logic within the driver codebase to ensure strict adherence to hardware-defined boundaries. The fix replaces the erroneous round-up operation with a round-down approach, effectively excluding the single page containing reserved CCS storage from the pool of allocatable memory. This adjustment ensures that the usable VRAM range ends precisely before the start of compression metadata, preventing any overlap between user-accessible memory and hardware-reserved regions. Additionally, developers have strengthened assertion checks to validate these boundaries more rigorously during debugging phases, ensuring that future regressions are caught earlier in the development cycle rather than manifesting as runtime failures in production environments.
From a security taxonomy perspective, this vulnerability aligns with CWE-120 Buffer Copy without Checking Size of Input and CWE-787 Out-of-bounds Write, as it involves writing to memory regions outside their intended allocation scope due to incorrect boundary calculations. The attack vector is classified under ATT&CK technique T1499 Endpoint Denial of Service via resource exhaustion or corruption, although in this context the denial of service arises from accidental hardware-software interaction conflicts rather than malicious exploitation. However, the underlying mechanism represents a potential path for privilege escalation if an attacker could reliably control which pages are allocated to sensitive kernel structures versus user-space applications, potentially leading to arbitrary code execution through memory corruption primitives.
The resolution underscores the importance of precise boundary management in low-level driver development, particularly when dealing with hardware features that operate independently of standard GPU submission pipelines. By ensuring that reserved hardware regions are strictly excluded from general-purpose allocators, the integrity of both system stability and potential security boundaries is preserved. This fix highlights how subtle arithmetic errors in memory layout calculations can lead to catastrophic failures in modern graphics stacks, emphasizing the need for rigorous testing across diverse hardware configurations with varying VRAM sizes and compression engine implementations.