CVE-2026-90047: Linux Kernel Privilege Escalation Vulnerability

CVE-2026-90047 Overview

CVE-2026-90047 affects the Linux kernel's drm/xe graphics driver for Intel discrete GPUs. The get_flat_ccs_offset() function rounds the flat Compressed Color Surface (CCS) storage base upward to 128K alignment. The rounded region is then handed to the VRAM allocator as usable memory, even though part of it actually belongs to the compression hardware.

On an Intel Battlemage G21 GPU with 16 GiB of VRAM, the raw base 0x3fafff800 rounds up to 0x3fb000000, publishing the last 2 KiB of page 0x3fafff000 as allocatable memory. The compression hardware silently overwrites that region without requiring page tables, buffer objects, or GPU submissions.

Critical Impact
Memory corruption occurs before userspace starts. On affected hardware, GPU page tables allocated in the reserved region lose entries, causing display compositor crashes and black-screen boot failures.

Affected Products

Linux kernel drm/xe driver on Intel discrete GPUs where flat CCS storage is not 128K aligned
Intel Battlemage G21 discrete GPU with 16 GiB VRAM (confirmed reproducer)
Any Xe-driver system where CONFIG_DRM_XE_DEBUG is disabled, silencing the flawed alignment assertion

Discovery Timeline

2026-09-16 - CVE-2026-90047 published to the National Vulnerability Database
2026-09-16 - Last updated in NVD database

Technical Details for CVE-2026-90047

Vulnerability Analysis

The flat CCS storage region holds compression metadata written directly by dedicated compression hardware. The driver must reserve this region so the VRAM allocator never treats it as free memory. get_flat_ccs_offset() reads the hardware base, scales it by the number of enabled L3 nodes, and applies round_up() to 128K.

Rounding the ceiling upward is the inverse of what the boundary requires. Any bytes between the true base and the rounded value are advertised as free VRAM while still being written by the compression engine. Allocated buffers placed in that tail are corrupted asynchronously and without any software trigger from the driver.

On the reproducing Battlemage system, a Mesa userspace VM's level-3 page table landed on the reserved tail on every cold boot. The compression hardware overwrote the page-table entry for the compositor's batch-buffer heap. The compositor's first GPU submission then faulted, gdm restarted indefinitely, and the system presented a black screen.

Inspecting the tail after boot revealed compression metadata patterns such as 0xcccc000000000000 and 0xcc77000000000000 written two bytes per sixteen, confirming the compression engine as the corrupting agent. This maps to a kernel driver flaw with local attack vector and high impact to confidentiality, integrity, and availability.

Root Cause

The root cause is an incorrect rounding direction inside get_flat_ccs_offset(). The scaled hardware base has no guarantee of 128K alignment. Rounding a "usable memory ends here" boundary upward extends the allocator's pool into hardware-owned memory. A debug assertion existed to catch misalignment, but it compared the offset against GSMBASE - ccs_size, a value that is itself 128K aligned. The assertion only matches when the base is already aligned, so it cannot fire in the misalignment case, and it is compiled out unless CONFIG_DRM_XE_DEBUG is set.

Attack Vector

Exploitation requires local access to a system running the vulnerable drm/xe driver on hardware exhibiting non-aligned flat CCS bases. No network vector applies. The corruption occurs automatically at driver initialization on affected hardware, meaning a local low-privileged user on such a system experiences memory integrity loss without action. A local attacker who can influence VRAM allocation placement may be able to steer sensitive buffers into the corrupted tail to induce denial of service or manipulate GPU state.

See the kernel commits referenced under Patch Information for the corrected boundary calculation and the replacement assertion that verifies CCS storage does not overlap with GSM.

Detection Methods for CVE-2026-90047

Indicators of Compromise

Repeated GDM or Wayland compositor restart loops after cold boot on Intel Xe-driver systems, particularly Battlemage G21 hardware
Unexpected GPU page faults on the compositor's first submission after boot
Compression metadata byte patterns such as 0xcccc000000000000 or 0xcc77000000000000 observed inside pages the VRAM allocator handed to userspace
Kernel logs from the xe driver reporting CCS offsets that are not 128K aligned when CONFIG_DRM_XE_DEBUG is enabled

Detection Strategies

Query /proc/version and installed kernel packages to identify hosts running drm/xe builds prior to the fix commits 348c3db4f152, 818bebeb63dd, and c96477e0cabf
Correlate GPU fault messages in dmesg with graphical session restarts recorded by systemd-journald
Inventory endpoints containing Intel discrete GPUs supported by the Xe driver and flag those on unpatched kernels

Monitoring Recommendations

Collect kernel ring buffer logs centrally and alert on repeated xe driver faults, MMU errors, or GPU HANG events
Monitor gdm and display-manager restart counts as a proxy for the black-screen failure mode
Track kernel version drift across Linux fleets to ensure timely uptake of stable-tree fixes

How to Mitigate CVE-2026-90047

Immediate Actions Required

Upgrade to a Linux kernel that includes commits 348c3db4f152, 818bebeb63dd, or c96477e0cabf, which replace round_up() with round_down() in get_flat_ccs_offset()
Prioritize workstations and servers with Intel Battlemage or other Xe-supported discrete GPUs
Verify the patched assertion is active by building with CONFIG_DRM_XE_DEBUG in test environments to confirm CCS storage no longer overlaps GSM

Patch Information

Upstream fixes are available in the stable trees. Reference the commits at Kernel Git Commit 348c3db, Kernel Git Commit 818bebeb, and Kernel Git Commit c96477e0. The fix rounds the CCS boundary downward to the allocator page size, excluding exactly one page on the reproducing hardware, and adds an assertion that fails if CCS storage runs into GSM.

Workarounds

Blacklist the xe kernel module on affected Battlemage systems until a fixed kernel is deployed, falling back to alternative drivers where hardware support allows
Where module unload is impractical, avoid cold boots into graphical targets and validate GPU workload integrity before running production tasks
Restrict local login on shared hosts running the vulnerable driver to reduce exposure to local privilege abuse scenarios

bash

# Verify running kernel and drm/xe module status
uname -r
modinfo xe | grep -E '^(version|filename)'

# Temporary mitigation: prevent xe from loading at boot
echo 'blacklist xe' | sudo tee /etc/modprobe.d/blacklist-xe.conf
sudo update-initramfs -u