CVE-2026-68298: Linux Kernel Privilege Escalation Flaw

CVE-2026-68298 Overview

CVE-2026-68298 is a resource leak vulnerability in the Linux kernel's Intel Xe direct rendering manager (DRM) driver. The flaw resides in the xe_vm_create() function within the drm/xe/vm subsystem. When drm_gpuvm_resv_object_alloc() fails, the error unwind path does not properly release resources allocated by xe_svm_init(). This leaves vm->svm.gpusvm partially initialized and leaks memory. For fault-mode VMs, the same error path also leaks the pagemap owner and pagemaps acquired via drm_pagemap_acquire_owner() and xe_svm_get_pagemaps(). Local users interacting with the Xe GPU driver can trigger the leak under allocation failure conditions.

Critical Impact
Repeated triggering of the error path can exhaust kernel memory and shared virtual memory (SVM) resources on systems using Intel Xe graphics, leading to denial of service.

Affected Products

Linux kernel builds containing commit 9e9787414882 ("drm/xe/userptr: replace xe_hmm with gpusvm")
Systems using the Intel Xe DRM driver with GPU shared virtual memory (SVM)
Both fault-mode and non-fault-mode Xe virtual machines

Discovery Timeline

2026-08-10 - CVE-2026-68298 published to NVD
2026-08-13 - Last updated in NVD database

Technical Details for CVE-2026-68298

Vulnerability Analysis

The vulnerability originates in the Xe DRM driver after commit 9e9787414882 made xe_svm_init() unconditional inside xe_vm_create(). This change extended initialization to also set up 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 inside xe_vm_create() was not adjusted.

When drm_gpuvm_resv_object_alloc() fails, the code executes an error path that only invokes xe_svm_fini() if the XE_VM_FLAG_FAULT_MODE flag is set. For non-fault-mode VMs, this leaves resources allocated by drm_gpusvm_init() orphaned. For fault-mode VMs, the path additionally acquires the pagemap owner and pagemaps, which are normally released by xe_svm_close(). The error path does not call xe_svm_close(), so those resources also leak.

Root Cause

The root cause is an asymmetric error unwind path. xe_svm_init() runs unconditionally on the success path, but the cleanup logic on failure remains conditional on XE_VM_FLAG_FAULT_MODE. This mismatch causes the driver to skip cleanup of state that was actually initialized.

Attack Vector

Exploitation requires local access with the ability to issue Xe DRM ioctls that create GPU virtual machines. An attacker who can repeatedly trigger allocation failures during VM creation can amplify the leak. Sustained triggering causes kernel memory exhaustion. The CVSS vector indicates local access with low privileges is sufficient.

No verified public exploit code is available. See the Kernel Git Security Fix for the authoritative patch and technical details.

Detection Methods for CVE-2026-68298

Indicators of Compromise

Growing unaccounted kernel slab allocations tied to drm_gpusvm structures on systems running the Xe driver
Repeated failed xe_vm_create() calls visible in kernel logs or DRM tracepoints
Progressive reduction in available kernel memory on Intel GPU workstations without corresponding userspace consumption

Detection Strategies

Enable kernel memory leak detection (kmemleak) on test systems to observe unreleased drm_gpusvm allocations after Xe VM creation failures
Monitor DRM ftrace events for xe_vm_create failures correlated with rising slab usage
Track dmesg output for Xe driver errors near allocation failure paths

Monitoring Recommendations

Baseline kernel slab usage on hosts with Intel Xe GPUs and alert on sustained growth in DRM-related caches
Log ioctl invocations against the Xe DRM device from unprivileged users to identify unusual patterns
Correlate GPU driver telemetry with host memory pressure alerts to detect exploitation attempts

How to Mitigate CVE-2026-68298

Immediate Actions Required

Apply the upstream Linux kernel patches referenced in the stable tree commits 279339aa8bdc, 9ac92736030f, and d2c6800ad180
Inventory hosts running kernels that include commit 9e9787414882 and prioritize them for update
Restrict access to the Xe DRM device node to trusted users where patching cannot be applied immediately

Patch Information

The fix calls xe_svm_fini() unconditionally on the err_svm_fini label, matching the unconditional xe_svm_init() call. It moves the vm->size = 0 assignment out of the conditional so the xe_vm_is_closed() assertion in xe_svm_fini() and xe_svm_close() holds for both modes. For fault-mode VMs, xe_svm_close() is now called before xe_svm_fini(), matching the ordering used in xe_vm_close_and_put(). The patch was cherry-picked from commit ca2a3587d577ba764e0fe628fb676244fc33ddd4. See the Kernel Git Patch Update.

Workarounds

Restrict permissions on /dev/dri/renderD* and /dev/dri/card* nodes so only trusted user accounts can issue Xe DRM ioctls
Disable the Xe driver on affected systems and fall back to the i915 driver where hardware supports it
Use kernel resource controls (cgroup v2 memory limits) on user sessions to bound the impact of leaked allocations

bash

# Verify the running kernel and check for the patched Xe module
uname -r
modinfo xe | grep -E '^(filename|version|srcversion):'

# Restrict access to DRM render nodes to a trusted group
sudo chgrp render /dev/dri/renderD128
sudo chmod 0660 /dev/dri/renderD128