HIGH 7.8

CVE-2026-53290: Linux Kernel Xe GPU Use-After-Free Privilege Escalation

A use-after-free vulnerability exists in the Linux kernel's GPU display driver (xe) within the EU stall stream closure routine. When a GPU monitoring stream is closed, the driver releases a reference to the device before fully shutting down and freeing the stream's resources. If this causes the device structure to be deallocated prematurely, subsequent cleanup code attempts to access memory that has already been freed, potentially leading to kernel crashes or privilege escalation. This flaw affects systems using the Intel Xe GPU driver on Linux and requires local access and user-level privileges to exploit.

Source data · NVD / CISA · public domain

CVSS
3.1 · 7.8 HIGH · CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Weaknesses (CWE)
CWE-416
Affected products
2 configuration(s)
Published / Modified
2026-06-26 / 2026-07-08

NVD description (verbatim)

In the Linux kernel, the following vulnerability has been resolved: drm/xe/eustall: Fix drm_dev_put called before stream disable in close In xe_eu_stall_stream_close(), drm_dev_put() is called before the stream is disabled and its resources are freed. If this drops the last reference, the device structures could be freed while the subsequent cleanup code still accesses them, leading to a use-after-free. Fix this by moving drm_dev_put() after all device accesses are complete. This matches the ordering in xe_oa_release(). (cherry picked from commit 35aff528f7297e949e5e19c9cd7fd748cf1cf21c)

3 reference(s) · View on NVD →

SEC.co analysis · AI-assisted, reviewed against source

Technical summary

CVE-2026-53290 is a use-after-free vulnerability in xe_eu_stall_stream_close() within the Linux kernel's Intel Xe DRM driver. The bug occurs because drm_dev_put() is invoked before the stream is disabled and its associated resources are deallocated. If drm_dev_put() reduces the device reference count to zero, it frees critical device structures while subsequent cleanup operations (stream disable, resource release) still hold pointers to them. This ordering violation violates the reference counting protocol and mirrors a pattern already corrected in xe_oa_release(). The fix reorders drm_dev_put() to execute after all device accesses complete, ensuring proper cleanup sequencing.

Business impact

Systems running Linux with the Intel Xe GPU driver are at risk of local privilege escalation or kernel instability. An unprivileged local user with GPU access can trigger the vulnerability by closing a stall stream, potentially gaining elevated privileges or crashing the kernel. For organizations relying on Xe-equipped systems (data centers, workstations with Intel Arc or Ponte Vecchio GPUs), this represents a direct path to privilege escalation and could disrupt service availability.

Affected systems

The Linux kernel is affected, specifically versions containing the vulnerable xe_eu_stall_stream_close() function. This impacts systems using Intel Xe GPU drivers, including systems with Intel Arc GPUs or Ponte Vecchio accelerators. Check your kernel version and verify whether the Xe DRM driver is enabled in your configuration.

Exploitability

Exploitability is practical. The vulnerability requires local access (not remote), user-level privileges (unprivileged execution), no special user interaction, and no unusual system configuration (AC:L indicates standard configurations are vulnerable). An attacker with a local account can deliberately close a GPU stall stream to trigger the use-after-free, potentially achieving privilege escalation or kernel code execution. CVSS score of 7.8 (HIGH) reflects the combination of local-only access with high impact on confidentiality, integrity, and availability.

Remediation

Apply the upstream Linux kernel patch that reorders drm_dev_put() to occur after stream disable and resource cleanup, matching the pattern used in xe_oa_release(). Verify the patch is included in your kernel version by checking the kernel release notes or commit hash 35aff528f7297e949e5e19c9cd7fd748cf1cf21c (cherry-picked upstream). For immediate mitigation, restrict GPU access on multi-tenant systems and revoke unprivileged user GPU capabilities where operationally feasible.

Patch guidance

Identify your current kernel version using `uname -r`. Check the upstream Linux kernel repository or your distribution's kernel changelog to confirm whether commit 35aff528f7297e949e5e19c9cd7fd748cf1cf21c is included. Major distributions (Red Hat, Ubuntu, SUSE) typically backport such fixes into stable kernel versions; verify against your vendor's advisory. If using an enterprise kernel, contact your vendor for the patched version number. Test patches in a non-production environment before deployment to ensure compatibility with your GPU workloads.

Detection guidance

Monitor kernel logs (`journalctl -k`, `dmesg`) for GPU-related crashes, use-after-free warnings, or Xe driver errors that correspond to stream closure operations. Enable CONFIG_DEBUG_LIST and CONFIG_DEBUG_OBJECTS in your kernel if feasible to catch use-after-free conditions at runtime. Audit process logs for failed GPU operations or unexpected privilege escalations following GPU-related system calls. Kernel sanitizers (KASAN) deployed in test environments can definitively identify use-after-free execution; consider running affected workloads under KASAN before patching critical systems.

Why prioritize this

Although this vulnerability requires local access and is not actively exploited in the wild (KEV status: false), its HIGH CVSS score (7.8) and privilege escalation path make it a priority for patch management. Multi-tenant systems, containers, and shared compute environments where unprivileged users can access GPU hardware should be patched urgently. Single-user or air-gapped systems with restricted GPU access may defer patching slightly, but the ease of exploitation (AC:L, PR:L) justifies rapid deployment in most threat models.

Risk score, explained

The CVSS 3.1 score of 7.8 reflects: Local attack vector (no network route), Low attack complexity (standard configuration), Low privileges required (unprivileged user can exploit), No user interaction needed, and High impact across confidentiality, integrity, and availability (privilege escalation and kernel crash). The score is not elevated to 9.0+ only because remote exploitation is not feasible and root-level damage is bounded by the kernel's privilege isolation.

Frequently asked questions

Can this be exploited remotely?

No. The vulnerability requires local access (AV:L) and cannot be triggered over a network. Only users with local shell access or GPU access on the target system can exploit it.

Do I need to recompile my kernel, or is a distribution patch sufficient?

A distribution kernel update (e.g., from Red Hat, Ubuntu, or SUSE) containing this fix is sufficient. You do not need to compile from source unless your distribution has not yet released a patched kernel version.

What if I don't use Intel Xe GPU hardware?

Systems without Xe GPUs (older Intel iGPUs, AMD GPUs, NVIDIA with nouveau) are unaffected by this specific vulnerability. However, verify your kernel configuration or driver in use to be certain.

Will this crash my system immediately, or is it just a potential risk?

This is a potential risk, not a guaranteed crash. The vulnerability is triggered only when a stall stream is closed under conditions that cause the device reference count to drop to zero. Most systems may not trigger this path, but the risk of privilege escalation or kernel instability warrants patching.

This analysis is provided for informational purposes and should not be considered legal or professional security advice. CVSS scores and vulnerability details are derived from official sources; verify current patch availability against your distribution's security advisory before deployment. Use-after-free vulnerabilities can have varied real-world impacts depending on system configuration, workload, and kernel hardening measures in place. SEC.co makes no warranty regarding the completeness or accuracy of detection or remediation guidance and recommends consulting with your kernel vendor or security team for environment-specific risk assessment. Source: NVD (public-domain), retrieved 2026-08-05. Analysis generated by SEC.co (claude-haiku-4-5).