Look up another CVE · open CVE-2026-53290 in the interactive tracker
CVE-2026-53290
drm/xe/eustall: Fix drm_dev_put called before stream disable in close
Published 2026-06-26 (4 months ago) by the Linux kernel CNA. Subsystem drivers/gpu. Debian urgency: unimportant.
What to do, per Debian release
Debian's own status for CVE-2026-53290 in every release this site tracks, and what each one means in practice. Every status below is the one the Debian Security Team publishes for this CVE. source
| Release | Status | Version | What this means |
|---|---|---|---|
| Debian 12bookworm | not affected | 6.1.190-1 | Nothing to do. bookworm never shipped the vulnerable code. |
| Debian 13trixie | not affected | 6.12.113-1 | Nothing to do. trixie never shipped the vulnerable code. |
| Debian 14forky | fixed | 7.0.10-1 | Update the kernel and reboot. Fixed in 7.0.10-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 7.0.10-1 | Update the kernel and reboot. Fixed in 7.0.10-1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
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)
Where it lives
The fix touches these files. If the subsystem is one you do not use, the practical exposure is lower, though the package is still the vulnerable one.
drivers/gpu/drm/xe/xe_eu_stall.c
- What this is
- INTEL DRM XE DRIVER (Lunar Lake and newer)MAINTAINERS section matched on drivers/gpu/drm/xe/ · intel-xe@lists.freedesktop.org · Supported
- Kernel module
- xe
Check it on the machine
grep -w CONFIG_DRM_XE /boot/config-$(uname -r)Reads the booted kernel's own configuration, on the machine and nowhere else. =y is built in, =m is a module, and an is not set line means the code is not there.
lsmod | grep -w xePrints a line if that module is loaded right now, and nothing if it is not. One that is not loaded can still be loaded later by anything that needs it.
Show whether Debian builds this, per release
Debian builds this, but not on every flavour. At least one release below builds the code on some of its kernel flavours and not on others, so the answer depends on the architecture and flavour installed. The build rule could not be established for 2 releases, so nothing is claimed about those.
- bookworm, trixie?
- forky, sidMnot built on amd64/cloud-amd64, arm64/arm64-16k, arm64/cloud-arm64, loong64/loong64, ppc64el/powerpc64le-64k, s390x/s390x
- ?
- not established - no Makefile entry for the affected file
- M
- a module where it is built at all; some flavours do not build it
Where a release above reads "not established", no build rule for the affected file was found in that release's kernel tree. That is a gap in this lookup, not a finding that the code is absent.
- Build switch
- CONFIG_DRM_XE
From the configuration Debian publishes for every kernel flavour it builds. It covers only the architectures Debian ships a linux-config package for, and nothing about a kernel you built yourself. Debian's own status above stays authoritative about the source package.MAINTAINERS kbuild Makefiles Debian linux-config packages
Signals
- Published
- 2026-06-26 (4 months ago)source
- CVSS
- 7.8 high
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:Hsource recompute it - Attack vector
- local (AV:L)source
- EPSS
- 0.12%, higher than 1.9% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- unimportantsource
- Subsystem
- drivers/gpu
Upstream fixes
The versions the CNA records as introducing and fixing this, and the commit for each. source
| Introduced | Fixed in | Commit |
|---|---|---|
| 6.15 | 6.18.33 | bebce43f34b5 |
| 6.15 | 7.0.10 | 84f2bfbe6e38 |
| 6.15 | 7.1 | dc2d9842c67d |
Why the CNA scored it this way
Quoted from the kernel CNA's own scoring file, word for word. A highlighted metric carries the most severe value CVSS v3.1 defines for it, which is what pushes the score up. source
- AV:LAttack vector, local
- The vulnerable close handler is reached from local userspace through the Xe DRM render-node ioctl path that opens an EU stall observation stream fd, then close/release on that fd. It is not reachable from network or adjacent protocols.
- AC:LAttack complexity, low
- Once an EU stall stream fd exists, the vulnerable cleanup ordering is exercised by closing that fd; there is no attacker-uncontrolled race to win in the close path itself. The final-reference lifetime condition is a normal DRM device lifetime state rather than a precise timing primitive.
- PR:LPrivileges required, low
- The default `xe_observation_paranoid` gate requires `CAP_PERFMON` or `CAP_SYS_ADMIN`, but the driver explicitly provides a sysctl allowing non-privileged users to access observation data. Under the required most-severe reasonable deployment rule, a basic local user with render-node access can reach the stream open/close path.
- UI:NUser interaction, none
- No victim interaction is needed after the attacker can issue the ioctl and close the returned stream fd. The attacker drives the relevant userspace operations directly.
- S:UScope, unchanged
- The vulnerable code is in the host kernel DRM driver and impacts the same kernel security authority. There is no evidence of a VM, IOMMU, or separate security-scope boundary crossing.
- C:HConfidentiality impact, high
- This is a use-after-free of DRM/Xe device-related structures before subsequent cleanup dereferences them. Per kernel CVSS guidance, UAF memory corruption is treated as capable of enabling high confidentiality impact through reclaimed-object control and memory disclosure primitives.
- I:HIntegrity impact, high
- The UAF occurs before hardware stream disable, buffer teardown, and stream free operations continue through freed object graphs. Per kernel CVSS guidance, such UAF memory corruption is treated as potentially enabling arbitrary write or control-flow compromise.
- A:HAvailability impact, high
- At minimum, dereferencing freed device structures in the close path can cause a kernel oops or panic. UAFs in kernel cleanup paths are therefore high availability impact.