Look up another CVE · open CVE-2026-74440 in the interactive tracker

CVE-2026-74440

drm/xe: Wait on external BO kernel fences in exec IOCTL

7.8 EPSS 0.1% AV:L

Published 2026-08-15 (2 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-74440 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	fixedDSA-6466-1 · 2026-08-25 · text	6.12.105-1	Update the kernel and reboot. DSA-6466-1 shipped the fix on 2026-08-25, in 6.12.105-1. A running kernel keeps the old code until the machine restarts.
Debian 14forky	fixed	7.1.8-1	Update the kernel and reboot. Fixed in 7.1.8-1. A running kernel keeps the old code until the machine restarts.
Debian unstablesid	fixed	7.1.8-1	Update the kernel and reboot. Fixed in 7.1.8-1. A running kernel keeps the old code until the machine restarts.
Debian 12bookworm · linux-6.12	fixedDLA-4788-1 · 2026-09-19 · text	6.12.107-1~deb12u1	Update the kernel and reboot. DLA-4788-1 shipped the fix on 2026-09-19, in 6.12.107-1~deb12u1. A running kernel keeps the old code until the machine restarts.

The vulnerability

What the bug is

Before arming a user job, xe_exec_ioctl() only added the VM's dma-resv KERNEL slot as a dependency. That slot covers rebinds and the kernel operations of the VM's private BOs, but not external BOs (bo->vm == NULL), which carry their kernel operations (evictions, moves, ...) in their own dma-resv KERNEL slot. The DMA_RESV_USAGE_KERNEL slot is the cross-driver contract for memory management operations that must complete before the BO or its backing store may be used: any accessor is required to wait on the KERNEL fences before touching the resv. By skipping the external BOs' KERNEL slots, the exec path violated that contract and could schedule a user job while a kernel operation on an external BO mapped by the VM was still in flight, racing against it and potentially reading or writing memory that was being moved. Replace the VM-only dependency with an iteration over every object locked by the exec, adding each object's KERNEL slot as a job dependency. This covers the VM resv (rebinds and private BOs) as well as every external BO, mirroring the drm_gpuvm_resv_add_fence() call that later publishes the job fence to the same set of objects. Long-running mode continues to skip this, as before. (cherry picked from commit a6b842acf3ddd1efc53a56de9260cfa718fb35e7)

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_exec.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 xe

Prints 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 1 release, so nothing is claimed about those.

bookworm?
trixieMnot built on amd64/cloud-amd64, arm64/arm64-16k, arm64/cloud-arm64, armel/rpi, ppc64el/powerpc64le-64k, s390x/s390x
forky, sidMnot built on amd64/cloud-amd64, arm64/arm64-16k, arm64/cloud-arm64, loong64/loong64, ppc64el/powerpc64le-64k, s390x/s390x
bookworm · linux-6.12Mnot built on amd64/cloud-amd64, arm64/arm64-16k, arm64/cloud-arm64, ppc64el/powerpc64le-64k

?: 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

Debian tracker CVE record NVD kernel CNA record

Signals

Published: 2026-08-15 (2 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.13%, higher than 2.2% 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.8	6.12.103	1738db550334
6.8	6.18.44	21976fe52584
6.8	7.1.8	5d363d00bc97
6.8	7.2	af80e2bfde93

Debian advisories

Advisory	Date	Shipped to	Debian
DLA-4788-1	2026-09-19	bookworm 6.12.107-1~deb12u1	tracker
DSA-6466-1	2026-08-25	trixie 6.12.105-1	tracker

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 bug is reached only through DRM_IOCTL_XE_EXEC on an Intel xe render node (/dev/dri/renderD*); xe_exec_ioctl() is the sole entry and there is no network, Bluetooth, or remote protocol path into this dma-resv synchronization code.
AC:LAttack complexity, low: An attacker controls both sides: they create external BOs (vm_id=0), bind them into a non-LR VM, drive VRAM pressure to start kernel evictions/moves, and submit concurrent execs, so the missing external-BO KERNEL-fence wait is reliably triggerable without victim-dependent timing.
PR:LPrivileges required, low: XE_EXEC is registered DRM_RENDER_ALLOW in xe_device.c, so any unprivileged local user with a render-node fd (typical desktop/Android/ChromeOS GPU clients) can reach xe_exec_ioctl(); no CAP_SYS_ADMIN or init-namespace root is required.
UI:NUser interaction, none: Exploitation is fully self-contained in the attacker's process via ordinary xe ioctls (GEM create, VM bind, exec queue create, exec); no victim mount, file open, or other cooperative action is needed beyond routine GPU access.
S:UScope, unchanged: The race corrupts GPU buffer backing stores and dma-resv ordering within the same kernel security authority; it does not cross a VM, hypervisor, or IOMMU isolation boundary and matches standard local kernel memory-safety impact rather than sandbox/VM escape.
C:HConfidentiality impact, high: Skipping each external BO's DMA_RESV_USAGE_KERNEL fence lets a user GPU job run while TTM eviction/move blits are still copying that BO, so the engine can read stale or partially moved physical pages and disclose contents of memory the caller should not observe.
I:HIntegrity impact, high: The same unsynchronized window lets GPU writes land on a backing store being relocated or on pages whose PTEs no longer match the BO, yielding attacker-influenceable corruption of buffer objects and GPU page-table state usable for privilege escalation primitives.
A:HAvailability impact, high: Racing user execs against in-flight kernel BO moves can hang or reset the GPU engine, trip fault handlers, and destabilize the xe driver stack; per kernel CVSS guidance, this class of memory-management race that can panic or wedge the device warrants High availability impact.