Linux: Missing Release of Memory after Effective Lifetime
CVE-2026-68298 is a high-severity missing release of memory after effective lifetime vulnerability in Linux, with a CVSS 3.1 base score of 7.8 out of 10. It can be exploited with local access to the system by an attacker with a low-privileged account, without any action from a user. The record lists versions 279339aa8bdcf9db40094cf2bcbd495c53dbe817, 9ac92736030f3395d970c300eaeb59ac258a0c3e, d2c6800ad1802bed72a6de1416536737f114f1d6 as the first without the flaw, so updating Linux to one of those releases or later removes the exposure. There is no confirmed exploitation so far. EPSS estimates a 0.13% chance of exploitation within 30 days, which is low compared with other CVEs.
High severity with no evidence of exploitation so far.
What to do
- Update Linux to 279339aa8bdcf9db40094cf2bcbd495c53dbe817 or 9ac92736030f3395d970c300eaeb59ac258a0c3e or d2c6800ad1802bed72a6de1416536737f114f1d6, whichever matches your release line, or a later version.
Affected products and versions
| Vendor | Product | Affected versions | Fixed in |
|---|---|---|---|
| Linux | Linux | 9e978741488261e117bb50e5dfcf8e4080990958 up to, but not including, 279339aa8bdcf9db40094cf2bcbd495c53dbe817; 9e978741488261e117bb50e5dfcf8e4080990958 up to, but not including, 9ac92736030f3395d970c300eaeb59ac258a0c3e; 9e978741488261e117bb50e5dfcf8e4080990958 up to, but not including, d2c6800ad1802bed72a6de1416536737f114f1d6; 6.18 | 279339aa8bdcf9db40094cf2bcbd495c53dbe817, 9ac92736030f3395d970c300eaeb59ac258a0c3e, d2c6800ad1802bed72a6de1416536737f114f1d6 |
Version data comes from the organisation that assigned the CVE. Confirm against the vendor advisory before deciding you are unaffected.
How the severity score breaks down
- Attack vector
- LocalThe attacker needs local access or must trick a user into running something.
- Attack complexity
- LowNo special conditions are needed; the attack works reliably.
- Privileges required
- LowA basic user account is enough.
- User interaction
- NoneNo action by a victim is required.
- Scope
- UnchangedImpact stays within the vulnerable component.
- Confidentiality
- HighAll data handled by the component can be read.
- Integrity
- HighData or code can be modified at will.
- Availability
- HighThe component can be taken down completely.
Vector: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H. Scored by CNA.
Official 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)
Source: the CVE record as published by its numbering authority, via NVD and CVE.org.
The underlying weakness: Missing Release of Memory after Effective Lifetime
The product does not sufficiently track and release allocated memory after it has been used, making the memory unavailable for reallocation and reuse.
How developers prevent this class of flaw
- Choose a language or tool that provides automatic memory management, or makes manual memory management less error-prone. For example, glibc in Linux provides protection against free of invalid pointers. When using Xcode to target OS X or iOS, enable automatic reference counting (ARC). To help correctly and consistently manage memory when programming in C++, consider using a smart pointer class such as std
- Use an abstraction library to abstract away risky APIs. Not a complete solution.
- Consider using the Boehm-Demers-Weiser garbage collector (bdwgc), which can help avoid leaks.
More Missing Release of Memory after Effective Lifetime vulnerabilities (CWE-401)
Timeline
- CVE record published.
- CISA published its SSVC assessment (exploitation: none, automatable: no, technical impact: total).
- Record last changed materially (score, affected products, status or references).
References
Other references
Recent Missing Release of Memory after Effective Lifetime vulnerabilities
- 8.8 High severity
- 7.8 High severity
- 7.8 High severity
- 7.5 High severity
- 8.4 High severity
- 7.5 High severity
Spotted an error? Tell us.