Linux kernel drm/xe: flat CCS storage published as usable VRAM, corrupting allocations
Impact
get_flat_ccs_offset() rounded the flat CCS base address up to 128K before treating everything below it as usable VRAM, so when the hardware base is not 128K aligned the driver hands the tail of a CCS page to the VRAM allocator. The compression hardware then overwrites whatever landed there, with no page-table entry, buffer object or GPU submission involved - on a Battlemage G21 with 16 GiB it clobbered a page table and broke the display stack on every cold boot. The damaged assertion that should have caught it could not fail and was compiled out without CONFIG_DRM_XE_DEBUG. The record gives no attacker-controlled path; the demonstrated effect is silent memory corruption of whatever the allocator places on that page. Relevant only where Intel Xe-class GPUs are deployed, which is a minority of accelerator fleets.
Who can reach it
Local, on a host running the xe driver with an affected Intel GPU whose scaled CCS base is not 128K aligned. No authentication step is described - the corruption occurs from driver initialisation onward, before userspace exists.
What to do
Take the stable kernel with commits 348c3db4f152 / 818bebeb63dd / c96477e0cabf, which rounds the offset down to page size instead of up and replaces the dead assertion with one that can fire. Applying it requires draining and rebooting each affected node. No mitigation short of the patch is described.
References
Related entries
- Linux kernel amdgpu: off-by-one in MST HDCP per-connector arrays sized 31 instead of 32CVE-2026-90289 · Linux kernel amdgpu display (AMDGPU_DM_MAX_DISPLAY_COUNT, MST HDCP per-connector arrays)High
- Linux kernel amdgpu DM: CRTC reset leaves a dangling state pointer when allocation failsCVE-2026-93175 · Linux kernel amdgpu display (amdgpu_dm_crtc_reset_state)High
- Linux amdkfd: use-after-free race when two threads destroy the same compute queueCVE-2026-97429 · Linux kernel amdkfd (destroy_queue_cpsch)High
- Linux amdkfd: missing bounds check on the CRIU-supplied SDMA queue idCVE-2026-97497 · Linux kernel amdkfd (allocate_sdma_queue restore_sdma_id bounds check)High
- Linux drm/virtio: virtio-gpu hands guest-physical addresses to the host on Xen PV, exposing another domain's memoryCVE-2026-98156 · Linux kernel drm/virtio (virtio-gpu resource backing, DMA API on Xen PV)High
- accel/amdxdna: device buffers could be exported over dma-buf when they were never meant to beCVE-2026-98436 · Linux kernel accel/amdxdna (AMD XDNA NPU device buffer dma-buf export)High
This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.