Skip to main content
VulnerabilityPublished Updated

CVE-2026-68298: Linux kernel · Memory Leak

Affects Linux kernelSource CVE Database V5

0

Not known to be exploited · CVSS 7.8 High · fixed in d2c6800ad1802bed72a6de1416536737f114f1d6 : patch Linux kernel soon.

Data as of 26 Oct 2026, 17:30 UTC

CVSS 3.1 base score
7.8High
How severe the flaw is on the 0–10 CVSS scale.
EPSS
0.1% chance of exploitation in 30 days – higher than 2% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.
CISA SSVC
Exploitation
No evidence of active exploitation and no public proof of concept
Automatable
Attackers cannot reliably automate steps 1–4 of the kill chain
Technical impact
Total control over the software or total information disclosure

CISA SSVC assessment, 2026-10-16.

Patch
Available – fixed in d2c6800ad1802bed72a6de1416536737f114f1d6, 279339aa8bdcf9db40094cf2bcbd495c53dbe817, 9ac92736030f3395d970c300eaeb59ac258a0c3e
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

Exploitation evidence

  1. Disclosed: evidence found.

    CVE published 10 Aug 2026

  2. Detectable: no evidence on record.

    No public nuclei template indexed

  3. Weaponised: no evidence on record.

    No public exploit code indexed in Metasploit or Exploit-DB

  4. Exploited in the wild: no evidence on record.

    Not in CISA KEV and no source reports exploitation

  5. Observed by OffSeq Mirage: no evidence on record.

    No attack traffic recorded by OffSeq Mirage sensors

A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 26 Oct 2026.

What to do

Upgrade Linux kernel to d2c6800ad1802bed72a6de1416536737f114f1d6, 279339aa8bdcf9db40094cf2bcbd495c53dbe817 or 9ac92736030f3395d970c300eaeb59ac258a0c3e.

Affected software

ProductAffectedFixed in
LinuxLinuxAffected
  • ≥ 9e978741488261e117bb50e5dfcf8e4080990958, < d2c6800ad1802bed72a6de1416536737f114f1d6
Fixed in
  • d2c6800ad1802bed72a6de1416536737f114f1d6
LinuxLinuxAffected
  • ≥ 9e978741488261e117bb50e5dfcf8e4080990958, < 279339aa8bdcf9db40094cf2bcbd495c53dbe817
Fixed in
  • 279339aa8bdcf9db40094cf2bcbd495c53dbe817
LinuxLinuxAffected
  • ≥ 9e978741488261e117bb50e5dfcf8e4080990958, < 9ac92736030f3395d970c300eaeb59ac258a0c3e
Fixed in
  • 9ac92736030f3395d970c300eaeb59ac258a0c3e
LinuxLinuxAffected
  • =6.18
Fixed in–

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)

References

Community reviews

Loading reviews…