CVE-2026-68428: Patch Linux KVM Module Reload UAF

The NVD published the CVE record on August 10, 2026, but the underlying upstream fix is older: Phil Rosenthal’s patch entered the Linux tree on July 21, after being authored on July 18. Fedora had already shipped the correction in its July 22

and corresponding Fedora 44 update. The CVE is newly cataloged, not a newly discovered bug or a newly released fix.

That timing matters for incident triage. A scanner flagging CVE-2026-68428 today does not necessarily mean a system is awaiting a new emergency kernel update; Fedora systems updated since the July 22 stable-kernel release may already carry the backport even though their visible upstream base is Linux 7.1.4, below the fixed upstream 7.1.6 release cited in the CVE record. Kernel version matching alone is not enough when distributions backport security fixes.

The stale pointer survives because kvm.ko does​

The bug sits in

, in the code that creates and destroys KVM MMU slab caches. KVM uses two caches in this path:

and

. During normal vendor-module shutdown,

destroys both caches.

Before the patch, it did not clear the two stored pointer variables afterward. That appears harmless if every component unloads together, but the pointer state lives in the core

module. A host can unload

while leaving

loaded, and the stale cache addresses then remain in memory as apparently valid state even though the underlying slab caches are gone.

On a later vendor-module load, KVM tries to recreate the caches. If creation of

fails, the initialization code enters its error cleanup route. The first pointer has been set to

, but

can still hold the address of the cache destroyed during the earlier unload. Calling

on that stale pointer produces the slab use-after-free detected by KASAN, Linux’s kernel address sanitizer.

The upstream patch is deliberately small: immediately after each cache destruction call, it sets the matching pointer to

. That brings the retained state in

into line with the lifetime of the objects it references and makes repeated cleanup safe.

This is a useful example of why a short patch should not be mistaken for a trivial condition. The defect is only two missing pointer resets, but it crosses module lifetimes: one module owns the long-lived state while another can be independently removed and reinserted.

The published reproducer needs more than a guest VM​

The upstream commit documents a reproduction on Linux 7.1.3 with KVM built as modules, KASAN enabled, and the Intel KVM vendor module enabled. The sequence is specific:

• The host loads kvm.ko and kvm-intel.ko, creating the two MMU caches.
• The host unloads only kvm-intel.ko, leaving the core KVM module loaded.
• The host reloads kvm-intel.ko while a test hook forces the cache-allocation failure path.

KASAN then reports the use-after-free when the error handler tries to destroy the old

pointer a second time. With the fix applied, the injected memory-allocation failure still returns

, but KASAN does not report invalid access.

That distinction narrows the immediate operational risk. The CVE record does not describe a guest workload independently forcing the condition, publish an exploit, or assign a CVSS score; NVD’s assessment remains pending as of August 11. The demonstrated path requires a KVM vendor-module reload followed by a particular allocation failure. In ordinary production environments, those module transitions are typically driven by an administrator, automation, a kernel-management process, or troubleshooting—not by routine VM execution.

The absence of a public guest-triggered exploit should not be read as a guarantee about all possible uses of a host-kernel use-after-free. It does mean administrators should avoid turning this record into a claim it does not make. There is no basis in the published record for calling CVE-2026-68428 a confirmed VM escape, a Windows vulnerability, or a remotely reachable attack on a KVM host.

The CVE’s scope is broader than the test case, but narrower than “all virtualization”​

The CVE record identifies the Linux kernel’s KVM/x86 MMU code and tracks the defect back to Linux 2.6.25. Its listed fixed upstream releases are Linux 6.6.148, 6.12.101, 6.18.42, and 7.1.6, with the correction also present by Linux 7.2-rc5. Those branch cutoffs are useful for kernel builders and distributions that closely track stable releases.

They are less useful as a universal fleet-management rule. Distribution kernels frequently retain an older-looking release number while carrying a backported patch. Fedora’s July update proves the point: it included Rosenthal’s KVM fix in a kernel package based on 7.1.4, before the CVE’s listed fixed 7.1.6 stable release. Red Hat-derived, Debian-derived, SUSE, Ubuntu, appliance, cloud, and hypervisor products should be checked against their own security advisories and changelogs rather than declared vulnerable solely because

reports an earlier upstream point release.

The concrete configuration requirements also matter:

• The affected KVM/x86 code must be present in the running kernel.
• KVM must be built or supplied as reloadable modules rather than permanently built into the kernel.
• A vendor module must be removed while kvm.ko stays loaded.
• A subsequent module initialization must hit the relevant allocation-failure cleanup path.

A host that uses Hyper-V to run Linux virtual machines is not running the Linux KVM module in the Windows host kernel. Microsoft’s Hyper-V documentation separately describes nested virtualization as exposing hardware virtualization extensions to guest VMs; that does not turn the Windows host’s Hyper-V stack into Linux KVM. The relevant edge case for Windows-focused labs is a Linux guest—potentially in a nested setup—where administrators themselves load and manage KVM modules inside that Linux environment.

The upstream reproducer explicitly tests

. The affected function is the shared KVM/x86 vendor-module initialization path, but the public record does not provide a separate AMD-specific reproducer. Administrators using KVM on AMD hardware should still consume their vendor’s corrected kernel package, rather than treating the Intel test configuration as an exclusion.

Fedora was ahead of the CVE listing​

Fedora’s security update notification dated July 22 lists “KVM: x86/mmu: Fix use-after-free on vendor module reload” in

; Fedora 44 received the corresponding

package. Fedora’s package history shows the fix was incorporated on July 21, immediately after upstream integration.

That is the report’s most important deployment finding. The newly visible CVE identifier can create the appearance of an unresolved August issue on systems whose package metadata already contains the fix. Security teams should reconcile CVE scanner output with the package changelog, build release, and distribution advisory status before opening a remediation exception or scheduling unnecessary maintenance.

Conversely, do not assume that a host is protected merely because it reports a newer major kernel. Custom kernels, vendor kernels, long-term support kernels, and hypervisor appliances can diverge from upstream stable trees. The patch is easy to identify in source:

should clear both

and

after passing them to

.

What KVM administrators should do now​

For active KVM infrastructure, the right response is straightforward: install the kernel update supplied by the operating-system or virtualization-platform vendor, then reboot into it under the organization’s normal kernel-change process. A reboot is necessary for a running host to use the corrected KVM code; installing a package alone does not replace the loaded kernel module.

Until that maintenance is completed, avoid operational procedures that unload and reload a KVM vendor module while retaining

, especially scripted recovery workflows that do so under memory pressure or after module-load errors. Do not attempt to reproduce the issue on a production hypervisor by forcing cache allocation failures or cycling

; the upstream test was designed for a KASAN-enabled diagnostic kernel.

For inventory purposes, administrators should determine whether a host has

,

, or

loaded and then check the installed kernel package’s security changelog. The material question is whether the vendor has backported the two-pointer cleanup fix, not simply whether a host’s version string is numerically at or above Linux 7.1.6.

CVE-2026-68428’s visible publication on August 10 closes a tracking gap, but the remediation path has been available in upstream and Fedora kernels since July. The immediate consequence for KVM operators is clear: verify the package, reboot into the corrected kernel, and remove module-reload workarounds that can exercise an error path the patch now makes safe.