0.0
NA
CVE-2026-68428
KVM: x86/mmu: Fix use-after-free on vendor module reload
Description

In the Linux kernel, the following vulnerability has been resolved: KVM: x86/mmu: Fix use-after-free on vendor module reload mmu_destroy_caches() destroys pte_list_desc_cache and mmu_page_header_cache, but leaves both pointers unchanged. The pointers live in kvm.ko, and therefore survive when a vendor module is unloaded while kvm.ko remains loaded. If creation of pte_list_desc_cache fails during a subsequent vendor module load, its assignment sets pte_list_desc_cache to NULL and the error path calls mmu_destroy_caches(). mmu_page_header_cache still points to the cache destroyed during the preceding vendor module unload. Passing that stale pointer to kmem_cache_destroy() causes a slab use-after-free. Reproduce the issue on a v7.1.3 kernel with CONFIG_KASAN=y, CONFIG_KASAN_GENERIC=y, CONFIG_KVM=m, and CONFIG_KVM_INTEL=m. A one-shot test hook forces pte_list_desc_cache to NULL on the second invocation of kvm_mmu_vendor_module_init(): 1. Load kvm.ko and kvm-intel.ko, creating both caches. 2. Unload only kvm_intel, leaving kvm.ko loaded. 3. Reload kvm_intel and force initialization through the -ENOMEM path. KASAN reports: BUG: KASAN: slab-use-after-free in kvm_mmu_vendor_module_init+0x5b/0x170 [kvm] ... kmem_cache_destroy+0x21/0x1d0 kvm_mmu_vendor_module_init+0x5b/0x170 [kvm] ... Allocated by task 16817: __kmem_cache_create_args+0x12c/0x3b0 __kmem_cache_create.constprop.0+0xb6/0xf0 [kvm] kvm_mmu_vendor_module_init+0x13b/0x170 [kvm] ... Freed by task 16820: kmem_cache_destroy+0x117/0x1d0 kvm_mmu_vendor_module_exit+0x21/0x30 [kvm] Clear both pointers immediately after destroying their caches so that the stored state reflects the caches' lifetime and repeated cleanup is safe. With the fix applied, the same injected vendor module reload fails with -ENOMEM as expected and produces no KASAN report.

INFO

Published Date :

Aug. 10, 2026, 1:20 p.m.

Last Modified :

Aug. 10, 2026, 1:20 p.m.

Remotely Exploit :

No

Source :

416baaa9-dc9f-4396-8d5f-8c081fb06d67
Affected Products

The following products are affected by CVE-2026-68428 vulnerability. Even if cvefeed.io is aware of the exact versions of the products that are affected, the information is not represented in the table below.

No affected product recoded yet

Solution
Clear cache pointers after destruction to prevent use-after-free.
  • Update the Linux kernel to the patched version.
  • Ensure cache pointers are cleared post-destruction.
  • Verify cache pointer states reflect cache lifetimes.
  • Test vendor module reload scenarios.
CWE - Common Weakness Enumeration

While CVE identifies specific instances of vulnerabilities, CWE categorizes the common flaws or weaknesses that can lead to vulnerabilities. CVE-2026-68428 is associated with the following CWEs:

Common Attack Pattern Enumeration and Classification (CAPEC)

Common Attack Pattern Enumeration and Classification (CAPEC) stores attack patterns, which are descriptions of the common attributes and approaches employed by adversaries to exploit the CVE-2026-68428 weaknesses.

We scan GitHub repositories to detect new proof-of-concept exploits. Following list is a collection of public exploits and proof-of-concepts, which have been published on GitHub (sorted by the most recently updated).

Results are limited to the first 15 repositories due to potential performance issues.

The following list is the news that have been mention CVE-2026-68428 vulnerability anywhere in the article.

The following table lists the changes that have been made to the CVE-2026-68428 vulnerability over time.

Vulnerability history details can be useful for understanding the evolution of a vulnerability, and for identifying the most recent changes that may impact the vulnerability's severity, exploitability, or other characteristics.

  • New CVE Received by 416baaa9-dc9f-4396-8d5f-8c081fb06d67

    Aug. 10, 2026

    Action Type Old Value New Value
    Added Affected [{'repo': 'https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git', 'vendor': 'Linux', 'product': 'Linux', 'versions': [{'status': 'affected', 'version': 'cb498ea2ce1d3f3c0bc0a2522241dca10263e437', 'lessThan': '6f4be73880302d5642c83a0813fdfe1f5fd4b6e3', 'versionType': 'git'}, {'status': 'affected', 'version': 'cb498ea2ce1d3f3c0bc0a2522241dca10263e437', 'lessThan': '32b9f89ed9e6d7a45075d64089c254a7f6e13695', 'versionType': 'git'}, {'status': 'affected', 'version': 'cb498ea2ce1d3f3c0bc0a2522241dca10263e437', 'lessThan': 'ec9daa8fd1b6f45545c9839dca55bd867fad9e13', 'versionType': 'git'}, {'status': 'affected', 'version': 'cb498ea2ce1d3f3c0bc0a2522241dca10263e437', 'lessThan': '43cfb20d62ffe49626d62beecfc32eb6f262191c', 'versionType': 'git'}, {'status': 'affected', 'version': 'cb498ea2ce1d3f3c0bc0a2522241dca10263e437', 'lessThan': '52f2f7c30126037975389aa04d24c506a5177c35', 'versionType': 'git'}], 'programFiles': ['arch/x86/kvm/mmu/mmu.c'], 'defaultStatus': 'unaffected'}, {'repo': 'https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git', 'vendor': 'Linux', 'product': 'Linux', 'versions': [{'status': 'affected', 'version': '2.6.25'}, {'status': 'unaffected', 'version': '0', 'lessThan': '2.6.25', 'versionType': 'semver'}, {'status': 'unaffected', 'version': '6.6.148', 'versionType': 'semver', 'lessThanOrEqual': '6.6.*'}, {'status': 'unaffected', 'version': '6.12.101', 'versionType': 'semver', 'lessThanOrEqual': '6.12.*'}, {'status': 'unaffected', 'version': '6.18.42', 'versionType': 'semver', 'lessThanOrEqual': '6.18.*'}, {'status': 'unaffected', 'version': '7.1.6', 'versionType': 'semver', 'lessThanOrEqual': '7.1.*'}, {'status': 'unaffected', 'version': '7.2-rc5', 'versionType': 'original_commit_for_fix', 'lessThanOrEqual': '*'}], 'programFiles': ['arch/x86/kvm/mmu/mmu.c'], 'defaultStatus': 'affected'}]
    Added Description In the Linux kernel, the following vulnerability has been resolved: KVM: x86/mmu: Fix use-after-free on vendor module reload mmu_destroy_caches() destroys pte_list_desc_cache and mmu_page_header_cache, but leaves both pointers unchanged. The pointers live in kvm.ko, and therefore survive when a vendor module is unloaded while kvm.ko remains loaded. If creation of pte_list_desc_cache fails during a subsequent vendor module load, its assignment sets pte_list_desc_cache to NULL and the error path calls mmu_destroy_caches(). mmu_page_header_cache still points to the cache destroyed during the preceding vendor module unload. Passing that stale pointer to kmem_cache_destroy() causes a slab use-after-free. Reproduce the issue on a v7.1.3 kernel with CONFIG_KASAN=y, CONFIG_KASAN_GENERIC=y, CONFIG_KVM=m, and CONFIG_KVM_INTEL=m. A one-shot test hook forces pte_list_desc_cache to NULL on the second invocation of kvm_mmu_vendor_module_init(): 1. Load kvm.ko and kvm-intel.ko, creating both caches. 2. Unload only kvm_intel, leaving kvm.ko loaded. 3. Reload kvm_intel and force initialization through the -ENOMEM path. KASAN reports: BUG: KASAN: slab-use-after-free in kvm_mmu_vendor_module_init+0x5b/0x170 [kvm] ... kmem_cache_destroy+0x21/0x1d0 kvm_mmu_vendor_module_init+0x5b/0x170 [kvm] ... Allocated by task 16817: __kmem_cache_create_args+0x12c/0x3b0 __kmem_cache_create.constprop.0+0xb6/0xf0 [kvm] kvm_mmu_vendor_module_init+0x13b/0x170 [kvm] ... Freed by task 16820: kmem_cache_destroy+0x117/0x1d0 kvm_mmu_vendor_module_exit+0x21/0x30 [kvm] Clear both pointers immediately after destroying their caches so that the stored state reflects the caches' lifetime and repeated cleanup is safe. With the fix applied, the same injected vendor module reload fails with -ENOMEM as expected and produces no KASAN report.
    Added Reference https://git.kernel.org/stable/c/32b9f89ed9e6d7a45075d64089c254a7f6e13695
    Added Reference https://git.kernel.org/stable/c/43cfb20d62ffe49626d62beecfc32eb6f262191c
    Added Reference https://git.kernel.org/stable/c/52f2f7c30126037975389aa04d24c506a5177c35
    Added Reference https://git.kernel.org/stable/c/6f4be73880302d5642c83a0813fdfe1f5fd4b6e3
    Added Reference https://git.kernel.org/stable/c/ec9daa8fd1b6f45545c9839dca55bd867fad9e13
EPSS is a daily estimate of the probability of exploitation activity being observed over the next 30 days. Following chart shows the EPSS score history of the vulnerability.