CVE-2026-68298

Received Received - Intake

Memory Leak in Linux Kernel DRM/XE VM

Publication date: 2026-08-10

Last updated on: 2026-08-17

Assigner: kernel.org

Description

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)

CVSS Scores

EPSS Scores

Probability:
Percentile:

Meta Information

Published

2026-08-10

Last Modified

2026-08-17

Generated

2026-08-30

AI Q&A

2026-08-10

EPSS Evaluated

2026-08-29

NVD

CVE-2026-68298

EUVD

EUVD-2026-55399

Affected Vendors & Products

Vendor	Product	Version / Range
linux_kernel	linux_kernel	*

Helpful Resources

Exploitability

CWE

KEV

CWE ID	Description
CWE-UNKNOWN

Attack-Flow Graph

Executive Summary

This vulnerability in the Linux kernel involves a resource leak in the drm/xe/vm component. When creating a VM, the xe_svm_init() function is called unconditionally but the cleanup function xe_svm_fini() is only called conditionally. This leads to partial initialization of the VM's SVM state and leaks resources allocated by drm_gpusvm_init(). For fault-mode VMs, additional resources like pagemap owner and pagemaps are also leaked because xe_svm_close() is not called on the error path.

Detection Guidance

This vulnerability is specific to the Linux kernel's drm/xe/vm component and requires kernel-level inspection. Detection involves checking kernel logs for errors related to xe_vm_create() or drm_gpuvm_resv_object_alloc() failures. Use commands like dmesg | grep xe_vm_create or journalctl -k | grep xe_vm_create to search for relevant errors.

Impact Analysis

This vulnerability can cause resource leaks in the Linux kernel's VM management, potentially leading to system instability or performance degradation. It may consume additional memory and system resources over time, affecting overall system operation.

Compliance Impact

This vulnerability does not directly affect compliance with standards like GDPR or HIPAA. It is a resource leak in the Linux kernel's DRM subsystem related to GPU virtual memory management, which does not involve data breaches or unauthorized access to sensitive information.

Mitigation Strategies

Apply the kernel patch that fixes the SVM leak in xe_vm_create(). Update your Linux kernel to a version containing commit 9e9787414882 or later. If patching is not immediately possible, consider disabling non-fault-mode VMs as a temporary workaround.

Hi! I’m here to help you understand CVE-2026-68298. Ask me anything about the vulnerability, its impact, or mitigation strategies.

0/70