CVE-2026-68428: 
Linux Kernel vulnerability analysis and mitigation

CVE-2026-68428 is a use-after-free vulnerability in the Linux kernel's KVM x86 MMU subsystem, triggered during vendor module reload. The flaw exists because mmu_destroy_caches() destroys pte_list_desc_cache and mmu_page_header_cache but does not reset their pointers, leaving stale references in kvm.ko after a vendor module (e.g., kvm-intel) is unloaded. On a subsequent vendor module reload that fails during cache creation, the error path calls mmu_destroy_caches() with a stale mmu_page_header_cache pointer, causing a slab use-after-free. The vulnerability affects Linux kernel versions from 2.6.25 up to (but not including) the fixed commits across stable branches (6.6.148, 6.12.101, 6.18.42, 7.1.6, and 7.2-rc5). It carries an estimated CVSS severity of Medium (GitHub Advisory, Feedly).

The root cause is improper lifecycle management of slab cache pointers in the KVM MMU layer (CWE class: Use After Free). When kvm_mmu_vendor_module_exit() calls mmu_destroy_caches(), both pte_list_desc_cache and mmu_page_header_cache are freed via kmem_cache_destroy(), but their pointer variables in kvm.ko are not set to NULL. If a subsequent kvm_mmu_vendor_module_init() call fails after setting pte_list_desc_cache = NULL (due to allocation failure), the error path invokes mmu_destroy_caches() again — passing the now-stale mmu_page_header_cache pointer to kmem_cache_destroy(), triggering the use-after-free. The fix clears both pointers immediately after destroying their respective caches, ensuring repeated cleanup is safe. Reproduction requires CONFIG_KASAN=y, CONFIG_KVM=m, and CONFIG_KVM_INTEL=m on a v7.1.3 kernel (GitHub Advisory).

Successful exploitation allows a local user with kernel module loading/unloading privileges to trigger a kernel slab use-after-free condition, potentially enabling local privilege escalation or arbitrary code execution in kernel context. The vulnerability is confined to systems running KVM as a loadable module with an Intel (or similar) vendor module, and requires the ability to load and unload kernel modules — limiting the attack surface to privileged local users or processes. There is no direct confidentiality or network-level impact, but kernel-level code execution could lead to full system compromise (GitHub Advisory, Feedly).

There is no public proof-of-concept exploit and no evidence of in-the-wild exploitation as of the disclosure date. Exploitation requires local access and the ability to load and unload kernel modules, significantly limiting the attack surface. No EPSS score or CISA KEV catalog entry has been reported for this CVE (GitHub Advisory, Feedly).

1. Prerequisite: Obtain local access to a Linux system with KVM loaded as a module (CONFIG_KVM=m, CONFIG_KVM_INTEL=m) and privileges to load/unload kernel modules (typically root or CAP_SYS_MODULE).
2. Initial state: Ensure both kvm.ko and kvm-intel.ko (or equivalent vendor module) are loaded, creating both pte_list_desc_cache and mmu_page_header_cache slab caches.
3. Unload vendor module: Run rmmod kvm_intel to unload only the vendor module, triggering mmu_destroy_caches() which frees both caches but leaves stale pointers in kvm.ko.
4. Trigger failure on reload: Reload the vendor module under conditions that cause pte_list_desc_cache creation to fail (e.g., via memory pressure or a test hook that forces -ENOMEM on the second invocation of kvm_mmu_vendor_module_init()).
5. Use-after-free triggered: The error path calls mmu_destroy_caches() with the stale mmu_page_header_cache pointer, invoking kmem_cache_destroy() on already-freed memory — resulting in a slab use-after-free that may be leveraged for kernel code execution (GitHub Advisory).

• Logs: KASAN kernel log messages such as BUG: KASAN: slab-use-after-free in kvm_mmu_vendor_module_init+0x5b/0x170 [kvm] in /var/log/kern.log or dmesg output.
• Logs: Kernel stack traces referencing kmem_cache_destroy, kvm_mmu_vendor_module_init, and kvm_mmu_vendor_module_exit in sequence.
• Process: Repeated loading and unloading of kvm_intel or kvm_amd modules by non-standard processes, visible via lsmod, dmesg, or audit logs (auditd with module load/unload rules).
• System: Unexpected kernel panics or system instability on hosts running KVM with modular vendor drivers, particularly following module reload events (GitHub Advisory).

Apply the upstream kernel patches that fix the issue by clearing both pte_list_desc_cache and mmu_page_header_cache pointers immediately after destroying their caches. Fixed commits are available for stable branches: 6.6.148 (6f4be73...), 6.12.101 (32b9f89...), 6.18.42 (ec9daa8...), 7.1.6 (43cfb20...), and 7.2-rc5 (52f2f7c...). As interim workarounds, restrict kernel module loading/unloading to trusted administrators, enable kernel module signature verification, and disable dynamic module loading if KVM hot-reload is not operationally required (GitHub Advisory, Feedly).