CVE-2026-53290

What it actually does

This is a use-after-free flaw in the Linux kernel Intel Xe DRM driver cleanup path for EU stall streams. In xe_eu_stall_stream_close(), the driver could release the DRM device reference with drm_dev_put() before the stream was disabled and its resources were fully freed. If that reference drop frees the underlying device structures, later cleanup code may continue to access freed kernel memory. The most likely impact is a local kernel crash or denial of service; depending on allocator state, hardening, and reachable object reuse, kernel memory corruption could potentially be used as part of a local privilege-escalation chain. The issue requires local interaction with the affected Xe DRM functionality and is not a direct remote network vulnerability.

Why it matters to the business

Systems using affected Linux kernels with the Intel Xe DRM driver may be susceptible to local instability or privilege-boundary risk from users, workloads, or containers that can access GPU DRM device nodes. The operational impact is primarily unexpected crashes, GPU/display disruption, host downtime, and possible escalation from an untrusted local workload to broader host compromise. Current public exploitation signals are low: EPSS is 0.00124, it is not listed in CISA KEV, it is not known to be used in ransomware campaigns, and no public exploit maturity is reported. However, kernel use-after-free bugs should still be patched through normal kernel maintenance because they can become useful primitives when combined with other local bugs.

How an attack unfolds

An attacker would need local access to a system running an affected Linux kernel with the Xe DRM driver available and permissions to interact with the relevant DRM device interface, such as a render or card node under /dev/dri. The attacker would exercise the EU stall stream functionality so that a stream object is opened or configured, then trigger the close path in a way that causes drm_dev_put() to drop the final device reference before the stream cleanup finishes. If the device structures are freed, the remaining cleanup code accesses stale memory. In a simple case this causes a kernel warning, KASAN report, Oops, GPU reset, or system crash. A more advanced attacker would attempt to shape kernel heap reuse around the freed object and convert the stale access into controlled memory corruption, potentially supporting local privilege escalation. There is no indication from the provided data of active exploitation, named threat actors, ransomware use, or a public exploit.

How to fix it

Apply a Linux kernel update from the relevant distribution or kernel vendor that includes the upstream fix for the Xe DRM driver cleanup ordering, associated with commit 35aff528f7297e949e5e19c9cd7fd748cf1cf21c or an equivalent backport. Because no specific affected package list or fixed package versions were provided, use vendor advisories and changelogs for the deployed kernel stream to identify the first fixed build. Reboot into the fixed kernel after installation; merely installing the package is not sufficient if the running kernel remains vulnerable. Where immediate patching is not possible, reduce exposure by restricting access to /dev/dri/card* and /dev/dri/renderD* to trusted users and workloads, removing untrusted users from video/render groups, avoiding GPU device passthrough to untrusted containers, and disabling or unloading the xe driver where it is not required. Treat these mitigations as temporary because they do not correct the kernel bug.

How to confirm the fix worked

Confirm remediation by verifying that the running kernel, not only the installed package, is a vendor-fixed build. Check the active kernel with uname -r and compare it to the distribution advisory for this issue. If validating from source or a custom kernel, confirm that xe_eu_stall_stream_close() performs stream disablement and resource cleanup before calling drm_dev_put(), matching the corrected ordering from the upstream fix. Confirm the xe module in use corresponds to the rebuilt or patched kernel. After reboot, review dmesg or journalctl -k for absence of KASAN, KFENCE, slab, Oops, or general-protection-fault reports involving xe_eu_stall_stream_close, drm_dev_put, or Xe EU stall stream cleanup. If a regression or proof-of-concept test is available from a trusted source, run it only in a non-production test environment and confirm it no longer crashes or triggers memory-safety diagnostics.

Typical attack path

1. Obtain local code execution on a Linux system with an affected kernel and the Intel Xe DRM driver loaded.
2. Confirm access to DRM device nodes such as /dev/dri/card* or /dev/dri/renderD* and the permissions required to exercise the affected Xe EU stall stream path.
3. Open or configure the affected EU stall stream interface through the Xe DRM driver.
4. Trigger stream closure or process/file-descriptor teardown so xe_eu_stall_stream_close() runs.
5. Cause drm_dev_put() to release the last DRM device reference before the stream is fully disabled and freed.
6. Rely on subsequent cleanup code accessing freed device memory, resulting in a crash or potential kernel memory corruption.
7. Optionally attempt heap grooming and object reuse to turn the use-after-free into a local privilege-escalation primitive.

How to detect it

Look for evidence of prior exploitation or attempted triggering in kernel and system logs rather than network telemetry, because this is a local kernel driver issue. Relevant sources include dmesg, journalctl -k, /var/log/kern.log, /var/log/messages, crash dump records such as kdump/vmcore, KASAN/KFENCE reports, audit logs for access to /dev/dri devices, endpoint telemetry showing processes opening DRM render or card nodes, and container runtime logs showing /dev/dri passthrough. Search for kernel warnings, Oops reports, use-after-free diagnostics, GPU resets, or crashes with stack traces containing xe_eu_stall_stream_close(), drm_dev_put(), xe_eu_stall, or the xe DRM module. Pay particular attention to events that follow execution by untrusted users, containers, GPU workloads, fuzzers, or unknown binaries accessing /dev/dri/card* or /dev/dri/renderD*. Absence of these artifacts does not prove non-exploitation, especially on systems without kernel memory sanitizers or persistent kernel logging, but their presence should trigger incident review and patch verification.

• xe_eu_stall_stream_close
• drm_dev_put
• xe_eu_stall
• KASAN: use-after-free
• KFENCE: use-after-free
• BUG: KASAN
• BUG: unable to handle page fault
• general protection fault
• kernel BUG at drivers/gpu/drm/xe
• WARNING: CPU:
• Oops:
• /dev/dri/renderD
• /dev/dri/card
• xe

What your security team should do

• Prioritize patching systems that run affected Linux kernels with Intel Xe GPU support and allow interactive users, build jobs, containers, VDI sessions, or other untrusted local workloads to access DRM devices.
• Reboot patched systems and verify the running kernel version; do not rely solely on package inventory that shows the update was installed.
• Until patched, restrict membership in groups that grant GPU/DRM access, commonly render or video, and avoid passing /dev/dri devices into untrusted containers or sandboxes.
• Monitor kernel logs for memory-safety reports and crashes involving the Xe DRM driver, especially on multi-user or container-hosting systems.
• Inventory systems with the xe driver loaded using module and hardware inventory data, and focus remediation on those with /dev/dri exposure to non-administrative users.
• Track distribution advisories for exact fixed kernel builds because fixed_versions were not provided in the input data.
• Treat any unexplained kernel crash involving xe_eu_stall_stream_close or drm_dev_put as potentially security-relevant and preserve logs, crash dumps, and process context for analysis.