CVE-2026-68298 in Linux
Summary
by MITRE • 08/10/2026
In the Linux kernel, the following vulnerability has been resolved:
drm/xe/vm: Fix SVM leak on resv obj alloc failure in xe_vm_create()
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)
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 08/10/2026
This vulnerability exists within the Intel graphics driver implementation in the Linux kernel, specifically affecting the xe (Xe) graphics driver's virtual memory management subsystem. The issue stems from improper resource cleanup during error paths in the virtual memory creation process, leading to memory leaks that can accumulate over time and potentially impact system stability. The vulnerability is classified as a resource leak under CWE-404, where the system fails to release allocated resources properly.
The technical flaw occurs in the drm/xe/vm subsystem where the xe_vm_create() function was modified to make xe_svm_init() unconditional as part of commit 9e9787414882. However, the error handling path does not properly account for all initialization states. When drm_gpuvm_resv_object_alloc() fails, the xe_svm_init() function has already succeeded in initializing vm->svm.gpusvm but the corresponding cleanup function xe_svm_fini() is only called when XE_VM_FLAG_FAULT_MODE is set. This creates a partial initialization state where resources allocated by drm_gpusvm_init() remain unreleased.
For fault-mode virtual machines, the situation is more complex as xe_svm_init() performs additional operations beyond simple initialization. It acquires pagemap ownership through drm_pagemap_acquire_owner() and retrieves pagemaps via xe_svm_get_pagemaps(). These resources are properly released by xe_svm_close() rather than xe_svm_fini(). However, in the error path where fault-mode VMs encounter allocation failures, xe_svm_close() is never invoked, resulting in leaks of both pagemap owners and pagemaps. This represents a compound resource leak scenario that can lead to significant memory consumption.
The operational impact of this vulnerability manifests as progressive memory leaks within the graphics subsystem, potentially leading to system performance degradation or resource exhaustion. The issue affects both fault-mode and non-fault-mode virtual machines, making it particularly concerning for systems with heavy graphics workloads. The leak occurs during normal operation when graphics driver initialization fails, meaning it can impact all users of Intel graphics hardware running affected kernel versions.
The fix implements two key changes to address the resource leaks properly. First, it ensures xe_svm_fini() is called unconditionally on error paths, matching the unconditional nature of xe_svm_init() and maintaining proper cleanup ordering. Second, for fault-mode VMs, it adds a call to xe_svm_close() before xe_svm_fini() to ensure proper release of pagemap resources, aligning with the cleanup sequence used elsewhere in the driver codebase. This fix follows established patterns within the kernel's memory management subsystem and addresses both the immediate resource leak issue and maintains consistency with existing error handling practices.
The vulnerability demonstrates a classic error handling anti-pattern where initialization functions are called unconditionally but corresponding cleanup functions are only invoked conditionally. This type of issue is commonly found in complex kernel subsystems where multiple initialization steps must be carefully coordinated with their respective cleanup paths, particularly in graphics drivers that manage sophisticated memory management structures. The fix resolves the issue by ensuring proper resource accounting and cleanup regardless of the execution path taken during virtual memory allocation failure conditions.
This vulnerability relates to ATT&CK technique T1490 for resource exhaustion attacks and CWE-404 for improper resource release. It represents a critical security concern in kernel space where resource leaks can be exploited to degrade system performance or potentially enable privilege escalation scenarios. The fix ensures proper memory management practices are maintained throughout all code paths, particularly during error conditions, which is essential for maintaining the stability and security of graphics subsystems in Linux environments.