CVE-2026-52976

What it actually does

This is a Linux kernel use-after-free flaw in the Intel Xe DRM GPU driver error handling path for exec queue creation. Under specific failure conditions in xe_exec_queue_create_ioctl(), an execution queue can be freed while still referenced from the VM compute queue list or hardware engine group list. Later kernel access to those stale references can trigger memory corruption, kernel crashes, or potentially privilege escalation if an attacker can reliably shape heap state and trigger reuse of the freed object.

Why it matters to the business

Systems using affected Linux kernels with the Intel Xe DRM driver enabled may be exposed to local denial of service and, depending on exploitability, possible local privilege escalation. Because exploitation requires local access to a device interface rather than remote network access, the primary operational risk is from compromised users, sandbox escapes, malicious workloads, or multi-user systems where untrusted users can access GPU/DRM devices. EPSS is currently low and there is no known KEV listing or public exploit maturity reported, but kernel memory corruption issues should still be prioritized on shared workstations, developer systems, GPU-enabled servers, and container or virtualization hosts that expose DRM devices to workloads.

How an attack unfolds

An attacker first needs local code execution on a Linux system where the affected Intel Xe DRM driver is loaded and the attacker can interact with the relevant DRM device node. The attacker then issues crafted ioctl calls that drive xe_exec_queue_create_ioctl() through error paths where queue setup partially succeeds and a later operation fails. In one path, the queue remains linked to the VM compute execution queue list; in another, it remains linked to a hardware engine group list. The queue is subsequently freed without being fully unlinked. By repeatedly triggering this condition and manipulating kernel heap allocation patterns, the attacker may cause the kernel to dereference the stale queue pointer. The most likely observable result is a kernel warning, GPU driver fault, or system crash; with sufficient control over memory reuse, the condition may be developed into kernel-mode code execution or privilege escalation.

How to fix it

Upgrade to a Linux kernel build that includes the upstream fix for the Xe DRM driver cleanup logic, specifically the change derived from commit 37c831f401746a45d510b312b0ed7a77b1e06ec8. If vendor fixed package versions are not yet identified, track the relevant distribution kernel advisories and install the first kernel update that references this vulnerability or the drm/xe exec queue cleanup fix. After updating, reboot into the fixed kernel; merely installing the package is not sufficient if the old kernel remains running. As temporary mitigation, restrict local access to DRM device nodes to trusted users only, avoid exposing /dev/dri devices to untrusted containers or sandboxes, disable or blacklist the xe driver where operationally acceptable, or boot a kernel configuration that does not load the vulnerable driver.

How to confirm the fix worked

Confirm the running kernel, not just the installed package, contains the fix. Validate by checking the active kernel version against the vendor advisory or by confirming the kernel source/package includes the drm/xe cleanup change for xe_exec_queue_create_ioctl(). Verify that the Xe driver is either updated, not loaded, or not present on systems where it is not required. Review permissions on /dev/dri/card* and /dev/dri/renderD* to ensure only intended users or workloads can access GPU device nodes. After remediation, monitor dmesg, journalctl, and kernel crash logs for recurring drm/xe, KASAN, use-after-free, general protection fault, or GPU hang messages that could indicate attempted triggering or remaining exposure.

Typical attack path

1. Obtain local execution on a Linux host with the affected Intel Xe DRM driver available.
2. Confirm access to DRM/GPU device nodes, such as /dev/dri/card* or /dev/dri/renderD*.
3. Open the DRM device and issue exec queue creation ioctls targeting the Xe driver.
4. Force or race specific allocation or setup failures during xe_exec_queue_create_ioctl().
5. Leave a freed execution queue referenced from a VM compute queue list or hardware engine group list.
6. Trigger later driver activity that walks or uses the stale list entry.
7. Cause a kernel crash, GPU driver instability, or attempt heap grooming for privilege escalation.

How to detect it

Look for signs of attempted local triggering rather than network indicators. Useful sources include kernel logs from dmesg and journalctl -k, persistent system journals, crash dumps, kdump/vmcore artifacts, GPU driver telemetry, auditd records for access to /dev/dri devices, EDR process telemetry showing unusual programs opening DRM device nodes, and container runtime logs showing GPU device passthrough. Investigate kernel messages mentioning drm/xe, xe_exec_queue_create_ioctl(), exec queue failures, use-after-free, KASAN, slab corruption, general protection faults, NULL pointer dereferences, GPU hangs, or unexpected reboots. Correlate these events with local user sessions, recently started containers, fuzzing tools, GPU test binaries, or unknown processes that opened /dev/dri/card* or /dev/dri/renderD*. There are no public threat actors or ransomware campaigns associated with this issue based on the provided data, so detection should focus on behavioral and crash artifacts.

• xe_exec_queue_create_ioctl
• drm/xe
• xe_exec_queue
• xe_hw_engine_group_add_exec_queue
• xe_hw_engine_group_del_exec_queue
• xe_vm_add_compute_exec_queue
• KASAN: use-after-free
• BUG: KASAN: use-after-free
• use-after-free in xe
• general protection fault
• BUG: kernel NULL pointer dereference
• kernel BUG at drivers/gpu/drm/xe
• GPU HANG
• /dev/dri/card
• /dev/dri/renderD
• drivers/gpu/drm/xe

What your security team should do

• Prioritize patching GPU-enabled Linux endpoints, shared developer workstations, multi-user systems, and container hosts that expose /dev/dri devices to workloads.
• Inventory systems with the Intel Xe DRM driver loaded using lsmod, modinfo, kernel package metadata, and hardware inventory data.
• Apply the vendor kernel update containing the drm/xe exec queue cleanup fix and reboot into the updated kernel.
• Temporarily restrict /dev/dri access and remove GPU device passthrough from untrusted containers or sandboxes until patching is complete.
• Monitor kernel logs and crash telemetry for drm/xe faults, KASAN use-after-free reports, GPU hangs, and abnormal local processes interacting with DRM device nodes.
• Treat exploitation evidence as a potential local privilege escalation attempt and perform host-level investigation if kernel memory corruption symptoms coincide with suspicious local activity.