Linux kernel KVM x86 MMU: use-after-free when a vendor module is reloaded after a failed init

UnscoredCVE-2026-68428Kernel, userspace & hypervisorcurated

Impact

mmu_destroy_caches() destroys pte_list_desc_cache and mmu_page_header_cache but leaves the pointers dangling in kvm.ko, which stays resident when kvm-intel or kvm-amd is unloaded. If a later vendor module load fails partway through, the error path hands a stale pointer to kmem_cache_destroy() and the slab allocator operates on freed memory. On a virtualized GPU host that runs tenant VMs under KVM this is host-side slab corruption in the hypervisor's page-table machinery. The trigger is narrow: it needs a KVM vendor module unload followed by a reload that fails, which is an administrative sequence, not something a guest can drive.

Who can reach it

Local root on the hypervisor host - whoever can rmmod and modprobe kvm-intel or kvm-amd. Guests cannot reach it; no unauthenticated or tenant-facing path.

What to do

Pick up the stable fix from the linked git.kernel.org commits or your distribution's backport, which requires a host kernel update and a reboot of each hypervisor node - drain VMs first. Until then, avoid unload/reload cycles of the KVM vendor module on live hosts; a clean reboot instead of a module reload sidesteps the bug. The record names no fixed release version.

References

https://nvd.nist.gov/vuln/detail/CVE-2026-68428 https://git.kernel.org/stable/c/034b7fa1f5846d69eb51f12ce6d1c71871e83c2d https://git.kernel.org/stable/c/42272b0f239f3a89f9c26a01cc37aee06138b1b7

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.