CVE-2026-64562 Affects Intel KVM Nested VMX, Not Windows

The Linux kernel project assigned the issue a CVSS 3.1 score of 8.8, with local attack access, low privileges, no user interaction, and high confidentiality, integrity, and availability impact. NVD published the record on August 4 and, as of August 9, has not issued its own CVSS assessment. That difference is procedural rather than a competing technical assessment: the available 8.8 score comes from kernel.org, while NVD’s enrichment is unfinished.

For administrators, the immediate action is to identify whether a Linux host is running Intel KVM with nested virtualization and shadow VMCS enabled, then move to a vendor kernel that contains the fix. Fedora’s July 22 security update for Fedora 44, kernel

, includes the patch. The upstream CVE record also identifies fixed upstream baselines in Linux

,

,

,

, and

.

A race between freeing state and clearing it​

The upstream commit, authored by Hyunwoo Kim and merged by KVM maintainer Paolo Bonzini on July 21, describes a lifecycle error rather than a conventional bounds-checking mistake. During nested-virtualization teardown,

releases the shadow VMCS, but the host-side

can still retain a pointer to that same object.

That would already be a dangerous ownership failure. The critical complication is scheduling: KVM’s cleanup path is asynchronous relative to

. A virtual CPU can migrate to another physical CPU before the stale pointer is cleared, after which

may execute Intel’s

instruction against a VMCS page that has already been freed.

The fix preserves the shadow VMCS until its explicit

has completed, then hides the VMCS and releases the page. In practical terms, it closes a use-after-free-style timing window in code that manages CPU virtualization state. This is precisely the kind of flaw where a clean shutdown sequence on one CPU can become unsafe after vCPU migration changes the order in which the remaining cleanup work executes.

The patch is small, but its placement matters. VMCS state is not ordinary application memory: it controls hardware virtualization transitions. KVM’s upstream documentation explains that a VMCS is the state structure used for VMX execution, with separate internal representations for the Linux host running KVM, the first-level guest hypervisor, and its nested guest. A stale association at this layer can put the host hypervisor in an invalid state while it is handling a guest-controlled virtualization workflow.

The affected setup is narrower than the CVSS score suggests​

This is an nVMX issue: nested Intel VMX. It requires a Linux machine serving as the level-0 KVM host, an Intel platform, and an L1 virtual machine acting as a hypervisor capable of launching an L2 guest. The Linux kernel’s own nested-KVM documentation calls those layers L0, L1, and L2: the bare-metal KVM host, the guest hypervisor, and the nested guest.

Nested virtualization is more common than it first sounds. It is used by cloud providers that offer nested virtualization, virtualization labs, CI systems, image builders, and organizations running a hypervisor within a VM. A Windows 11 or Windows Server guest using Hyper-V can be an L1 workload in a Linux KVM environment if the Linux host exposes Intel VMX to it. In that case, the Windows guest is part of the affected deployment pattern, but the vulnerable component remains the Linux KVM host kernel.

The flaw is not a Windows kernel vulnerability, a Microsoft Hyper-V vulnerability, or a guest operating-system update problem. Patching Windows inside a nested VM does not repair the vulnerable

code on the Linux host. Conversely, Windows systems running Hyper-V directly on bare metal are outside this CVE’s stated scope.

AMD systems are also outside the direct scope. KVM has separate nested virtualization implementations for Intel VMX and AMD SVM. The vulnerable file is in the Intel VMX path, and the patch title explicitly identifies nVMX. Administrators should not turn that into a reason to ignore general KVM patching on AMD infrastructure, but CVE-2026-64562 itself is not an nSVM advisory.

A quick exposure check on Intel KVM hosts is:

cat /sys/module/kvm_intel/parameters/nested
cat /sys/module/kvm_intel/parameters/enable_shadow_vmcs

A

or

for both values indicates that the host has the features most relevant to this flaw enabled. That is an exposure indicator, not a verdict: a host also needs to be actually running nested VMX workloads for the vulnerable path to be meaningful.

The kernel documentation notes that nested virtualization has been enabled by default in upstream KVM since Linux 4.20, although distributions may override that default. It also notes that shadow VMCS is enabled by default on capable Intel systems, generally Haswell-era processors and later. That combination means administrators should not assume a KVM server is insulated simply because nobody remembers explicitly enabling nested virtualization years ago.

Fedora has shipped the fix; enterprise status needs package-level checking​

Fedora’s advisory for

lists “KVM: nVMX: Hide shadow VMCS right after VMCLEAR” in its July 21 changelog. The Fedora package listing also shows the patch in the

update stream. That is independent confirmation that the fix was backported into a released distribution kernel rather than remaining only in Linus Torvalds’ development tree.

The CVE record identifies five stable-tree fix commits and says the issue is resolved in Linux

,

,

,

, and

. Those are useful upstream reference points, but administrators should not treat

as the whole answer on enterprise distributions. Red Hat, SUSE, Ubuntu, Oracle Linux, and other vendors commonly backport security fixes to long-supported kernels while retaining an older-looking base version.

There is a second reason to avoid simplistic version matching: the upstream fix references an earlier 2016 KVM change,

, as the commit that introduced the condition being corrected. The CVE metadata meanwhile presents an affected-version range beginning at Linux 4.9. Linux kernel version metadata often describes upstream lineage rather than every distribution’s exact patch set; it does not reliably account for vendor backports, downstream configuration choices, or historical stable-tree imports.

The operational rule is straightforward: check the vendor advisory and installed package build, not only the upstream version number. Fedora administrators can confirm that their installed kernel is at or beyond the distribution’s fixed build. Administrators on other distributions should wait for, or locate, their vendor’s advisory for CVE-2026-64562 and match the fixed package revision it specifies.

The published record does not establish a public exploit​

The CVE’s 8.8 score deserves prompt attention in multi-tenant or security-sensitive KVM environments, particularly where users can operate L1 hypervisors or execute nested VM workloads. But the score should not be read as proof of a demonstrated guest-to-host breakout.

The kernel commit explains the race and the invalid VMCS lifetime, but it does not provide an exploit chain, a proof of concept, a reliability analysis, or evidence of exploitation in the wild. NVD has not yet added analysis beyond ingesting the CVE record. No separate public security advisory identified during review describes confirmed exploitation.

That absence does not reduce the need to patch. It does change the immediate response from “assume every KVM host is remotely compromisable” to a prioritized maintenance task centered on hosts that actually expose nested Intel virtualization. An organization with an internal KVM lab where only trusted administrators run L1 hypervisors has a different urgency profile from a cloud or CI environment that delegates L1 VM control to tenants, developers, or automated workloads.

If patching must wait, disabling nested virtualization on affected Intel KVM hosts removes the relevant nVMX path, provided active nested workloads can be stopped and the

module can be safely reloaded. That is a compensating control, not a substitute for a fixed kernel, and it may break Windows Hyper-V-in-VM deployments, nested KVM labs, and virtualization test pipelines.

The concrete next step is to inventory Intel KVM hosts where both

and

are enabled, map them to the distributions’ fixed kernel packages, and schedule host reboots after updating. Systems running only conventional single-layer VMs should be recorded as outside the exposed configuration rather than consuming the same emergency window as nested-virtualization infrastructure.

References​

1. Primary source: NVD / Linux Kernel
   Published: August 9, 2026 at 8:41 AM UTC
   
   https://nvd.nist.gov/vuln/detail/CVE-2026-64562
2. Security advisory: MSRC
   Published: August 9, 2026 at 8:41 AM UTC
   Original feed URL
   
   

   Security Update Guide - Microsoft Security Response Center

   msrc.microsoft.com