CVE-2026-64517: Linux Kernel Use-After-Free Vulnerability

CVE-2026-64517 Overview

CVE-2026-64517 is a double-free vulnerability in the Linux kernel's Intel Xe GPU driver, specifically within the Graphics System Controller (GSC) initialization path. The flaw exists in xe_gsc_init_post_hwconfig(), where the error path explicitly frees a buffer object (BO) that was allocated with xe_managed_bo_create_pin_map() by calling xe_bo_unpin_map_no_vm(). Because the managed BO already has a devm cleanup action registered, the same allocation is released twice when devm unwinds during probe failure. The upstream fix removes the explicit free and lets devm handle cleanup, matching the behavior of all other callers.

Critical Impact
A double-free during Xe GPU driver probe failure can corrupt kernel memory allocator state, leading to denial of service or potential memory-safety exploitation on affected systems.

Affected Products

Linux kernel builds including the drm/xe GPU driver with GSC support
Systems using Intel GPUs handled by the Xe kernel-mode driver
Distributions shipping kernels prior to the backported fixes referenced in commits 2c890e71, 7cb975fc, 889f70de, and d3ded53f

Discovery Timeline

2026-07-25 - CVE-2026-64517 published to NVD
2026-07-25 - Last updated in NVD database

Technical Details for CVE-2026-64517

Vulnerability Analysis

The vulnerability resides in the Intel Xe Direct Rendering Manager (DRM) driver, in the GSC initialization routine xe_gsc_init_post_hwconfig(). This function allocates a buffer object using xe_managed_bo_create_pin_map(), which internally registers a device-managed (devm) cleanup callback so the BO is released automatically when the device is torn down.

The original error path in the function called xe_bo_unpin_map_no_vm() on the BO before returning the error code. When probe subsequently fails and devm unwinds its action list, the same BO is freed a second time via the registered managed cleanup. This is a classic double-free [CWE-415] condition triggered on the initialization error path.

Double-free defects corrupt the kernel's slab allocator metadata. Depending on allocator state and adjacent objects, this can cause immediate kernel panic, use-after-free primitives on subsequent allocations, or memory-safety issues suitable for local privilege escalation in some scenarios.

Root Cause

The root cause is a lifetime-management mismatch. Buffer objects allocated with xe_managed_bo_create_pin_map() are owned by devm and must not be freed explicitly by the caller. The error path violated that contract by calling xe_bo_unpin_map_no_vm() directly, duplicating the release that devm performs automatically.

Attack Vector

The defect is reachable only through the Xe driver's probe error path, meaning a system must attempt to initialize an Intel Xe-managed GPU and encounter a failure after the managed BO is allocated. Triggering the bug therefore requires conditions that cause xe_gsc_init_post_hwconfig() to fail during device probe, such as hardware faults, firmware load errors, or resource constraints. Exploitation is local and depends on kernel-mode allocator state at the moment of the double-free.

// Vulnerable pattern (conceptual, based on the upstream commit message)
// The managed allocator registers a devm cleanup for the BO.
// The error path then frees the same BO explicitly, causing a double-free
// once devm unwinds during probe failure.
//
// See kernel commits 2c890e71, 7cb975fc, 889f70de, d3ded53f for the exact fix.

Detection Methods for CVE-2026-64517

Indicators of Compromise

Kernel oops or panic messages referencing xe_gsc_init_post_hwconfig, xe_bo_unpin_map_no_vm, or xe_managed_bo_create_pin_map in dmesg or journalctl -k output
SLUB/SLAB allocator warnings such as double free or corruption and kernel BUG at mm/slub.c correlated with Xe driver load
Repeated Xe driver probe failures on systems with Intel GPUs, visible via modprobe xe errors or lspci -k showing no driver bound

Detection Strategies

Inventory running kernel versions across Linux hosts and flag systems whose kernel predates the fixes in commits 2c890e71, 7cb975fc, 889f70de, and d3ded53f
Enable CONFIG_SLUB_DEBUG and CONFIG_KASAN on test systems to catch double-free events during Xe driver initialization
Monitor kernel logs for driver probe failures immediately followed by allocator corruption messages

Monitoring Recommendations

Forward kernel logs to a centralized logging or SIEM platform and alert on xe, gsc, and slub correlated events
Track kernel crash dumps via kdump and inspect stack traces referencing Xe GSC symbols
Baseline expected Xe driver load behavior on GPU-equipped fleets and alert on new probe-failure patterns after kernel updates

How to Mitigate CVE-2026-64517

Immediate Actions Required

Apply the vendor-provided kernel update containing the upstream fix as soon as it is available for your distribution
Identify hosts with Intel GPUs bound to the Xe driver and prioritize their patching
Where patching is not immediately possible, review kernel logs for repeated Xe probe failures and address the underlying hardware or firmware faults that trigger the error path

Patch Information

The fix removes the explicit xe_bo_unpin_map_no_vm() call from the error path in xe_gsc_init_post_hwconfig(), leaving cleanup to the devm action already registered by xe_managed_bo_create_pin_map(). The corrected behavior is consistent with all other callers of that allocator. Reference the following upstream commits: Kernel Commit 2c890e71, Kernel Commit 7cb975fc, Kernel Commit 889f70de, and Kernel Commit d3ded53f.

Workarounds

Blacklist the xe module on systems that do not require Intel Xe GPU functionality until a patched kernel is deployed
Where possible, use the older i915 driver for supported Intel GPUs instead of xe on unpatched kernels
Address firmware and hardware conditions that force the GSC initialization error path, since the defect is only reachable when probe fails

bash

# Prevent the vulnerable module from loading until the kernel is patched
echo 'blacklist xe' | sudo tee /etc/modprobe.d/blacklist-xe.conf
sudo update-initramfs -u

# Verify the running kernel version after patching
uname -r