CVE-2026-68298

What the bug is

Commit 9e9787414882 ("drm/xe/userptr: replace xe_hmm with gpusvm") made xe_svm_init() unconditional in xe_vm_create() and extended it to also initialize a "simple" gpusvm state for non-fault-mode VMs. The matching xe_svm_fini() call in xe_vm_close_and_put() was updated to run unconditionally, but the error unwind path in xe_vm_create() was not. On the drm_gpuvm_resv_object_alloc() failure path, xe_svm_init() has already succeeded but xe_svm_fini() is only called when XE_VM_FLAG_FAULT_MODE is set. For non-fault-mode VMs this leaves vm->svm.gpusvm partially initialized and leaks the resources allocated by drm_gpusvm_init(). For fault-mode VMs, xe_svm_init() additionally acquires the pagemap owner via drm_pagemap_acquire_owner() and the pagemaps via xe_svm_get_pagemaps(). Those resources are released by xe_svm_close(), not xe_svm_fini(). On the same error path, xe_svm_close() is not called either, so fault-mode VMs leak the pagemap owner and pagemaps. Fix both leaks: - Call xe_svm_fini() unconditionally on the err_svm_fini path, matching the unconditional xe_svm_init() call. Move the vm->size = 0 assignment out of the conditional so the xe_vm_is_closed() assert in xe_svm_fini() (and xe_svm_close()) holds for both modes. - Call xe_svm_close() for fault-mode VMs before xe_svm_fini(), matching the ordering used in xe_vm_close_and_put(). (cherry picked from commit ca2a3587d577ba764e0fe628fb676244fc33ddd4)

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_vm.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

?

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-08-10 (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.1% 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.18	6.18.42	279339aa8bdc
6.18	7.1.6	9ac92736030f
6.18	7.2	d2c6800ad180