Cloudanix VulnDB

CVE-2026-68428

None

CVSS

—

EPSS

0.2%

Published

Aug 10, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A bug in Linux kernel memory handling for virtual machines can cause crashes if certain support modules are unloaded and reloaded in a particular sequence.

Exploitation
Local Privilege
Attacker needs
High Privilege
Complexity
High
Impact
Privilege Gain
Component
OS kernel
Class
Use After Free
Remediation
Patch
Effort
Low
Patch risk
Low

What it actually does

Use-after-free in KVM x86 MMU when mmu_destroy_caches is called on stale pointers to pte_list_desc_cache and mmu_page_header_cache after vendor module unload/reload cycles, specifically when cache creation fails on reload.

Why it matters to the business

Kernel instability, crashes, or memory corruption on Linux hosts running KVM with modular vendor drivers, increasing downtime risk for virtualized workloads during module reload operations.

How an attack unfolds

An attacker with module load/unload privileges unloads a KVM vendor module while kvm.ko stays loaded, then forces a reload that fails during cache initialization, causing the error path to invoke kmem_cache_destroy on a previously destroyed stale cache pointer.

How to fix it

Apply upstream fix that nulls both cache pointers immediately after kmem_cache_destroy calls. Rebuild and deploy updated kernel containing the corrected mmu_destroy_caches logic.

How to confirm the fix worked

Confirm pointers are cleared after cache destruction, reproduce vendor module reload under CONFIG_KASAN, and verify no slab-use-after-free reports occur on repeated init/exit cycles.

Typical attack path

  1. Unload KVM vendor module (e.g., kvm-intel) leaving kvm.ko resident
  2. Reload vendor module and force initialization failure path
  3. Trigger mmu_destroy_caches with stale pointer resulting in slab use-after-free

How to detect it

Scan kernel logs and KASAN reports for slab-use-after-free involving kvm_mmu_vendor_module_init and kmem_cache_destroy during vendor module reload sequences.

  • BUG: KASAN: slab-use-after-free in kvm_mmu_vendor_module_init
  • kvm_mmu_vendor_module_init+0x5b/0x170 [kvm]
  • kmem_cache_destroy+0x21/0x1d0
  • kvm_mmu_vendor_module_exit

What your security team should do

  • Prioritize kernel updates for KVM hosts
  • Restrict unprivileged module loading via kernel lockdown or module signing
  • Test module reload sequences in staging environments with KASAN enabled

The record

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.

Affected packages

Ecosystem Package Introduced Fixed