That conclusion is important because the National Vulnerability Database record currently lists the issue as a resolved Linux-kernel vulnerability across a broad range of releases, starting at Linux 3.18 and ending with fixes in 5.10.261, 5.15.212, 6.1.178, 6.6.145, 6.12.96, 6.18.39, and 7.1.4. Yet NIST has assigned no CVSS score, no CWE, and no impact assessment as of August 9, 2026. The public description contains a debug warning produced by syzkaller, not a crash, information disclosure, privilege-escalation path, or attack scenario.
The practical recommendation is straightforward: apply your distribution’s normal kernel updates, especially on Intel KVM hosts that use nested virtualization. But security teams should avoid inflating this CVE into an emergency incident without evidence that is absent from both the CVE record and the upstream patch discussion.
The patch changes when KVM reads nested VMCS state
CVE-2026-64604 is in
arch/x86/kvm/vmx/vmx.c, Linux’s Intel VMX implementation for KVM. VMX is Intel’s hardware virtualization architecture; the corresponding AMD implementation is KVM SVM, which this particular change does not touch.
The affected function updates CR8 interception handling. CR8 is tied to the x86 task-priority register mechanism used by the local APIC. In virtualized systems, KVM sometimes must tell the processor to trap—or intercept—changes to that state so it can emulate or coordinate interrupt-priority behavior correctly.
For nested virtualization, KVM has more than one layer of virtual-machine control data. The first-level hypervisor is the Linux host running KVM; a guest can itself run another hypervisor, creating an L2 guest.
vmcs12is the control structure representing the VMCS configured by the L1 guest for its L2 guest.
Before the patch,
vmx_update_cr8_intercept()retrieved
vmcs12unconditionally. Sean Christopherson’s upstream fix changes that behavior so KVM retrieves it only when the vCPU is actually in guest mode. That small condition avoids calling
get_vmcs12()during vCPU creation, when lockdep’s required locking conditions are not present.
The warning in the CVE record shows the exact sequence: KVM creates a vCPU, resets its local APIC state, reaches CR8 interception handling, and calls
get_vmcs12(). Lockdep then objects because the vCPU mutex is not held in that initialization context. The report is a diagnostic assertion from a debug-oriented kernel facility, not proof that memory has been corrupted or that a guest can seize control of the host.
This CVE is a companion change, not the underlying VM-entry repair
The context omitted by the short CVE description changes how this issue should be read. Christopherson submitted the patch as part of a two-patch KVM series titled “Fix VM-Entry fail due to stale CR8 intercept.” The series addressed a separate correctness problem: KVM could fail to refresh the
TPR_THRESHOLDstate after a processor-priority update, potentially violating an Intel VMX consistency check during VM entry.
Carlos López’s paired patch recomputes CR8 interception state whenever the processor priority register changes. That is the functional correction in the series. The CVE-assigned patch makes the new behavior safe for lockdep-enabled testing and for the vCPU-creation path by avoiding an unnecessary
vmcs12access outside guest mode.
In other words, the public CVE text says the patch is preparing for “a future change,” while the upstream review record shows that the relevant CR8 update change was already the second patch in the same submitted series. The wording is not false, but it obscures the relationship: CVE-2026-64604 is the enabling cleanup that lets the companion CR8-refresh fix run without triggering a lockdep warning.
That distinction affects prioritization. If an environment is seeing VM-entry failures associated with stale CR8 or
TPR_THRESHOLDstate, administrators need the complete stable update that includes the patch series—not merely a cherry-pick of CVE-2026-64604. Conversely, applying this CVE’s three-line VMX change alone was never intended to alter normal guest behavior.
The broad affected-version range should not be mistaken for broad exposure
The NVD entry says Linux releases before the listed fixed stable versions are affected, with a starting point of Linux 3.18. That is a source-code tracking statement, not a description of every machine’s real-world exposure.
The warning requires a comparatively specific set of conditions:
- The host must be running Linux KVM on an Intel VMX-capable processor.
- The relevant KVM VMX code must be available and in use.
- The CR8-intercept update must occur in the vCPU initialization or reset path implicated by the report.
- The kernel must be configured so lockdep can detect and report the locking assertion.
- Nested-virtualization handling is central to the
vmcs12access being corrected.
A typical Linux desktop, a non-virtualizing server, or an AMD-based KVM host is therefore not in the direct path described by this CVE. Neither is a Windows PC simply because it runs virtualization software. Windows Hyper-V does not use Linux KVM, and Windows guests do not gain an exposure merely by running under a Linux KVM host.
For Windows administrators, the relevant deployment is a Linux KVM host running Windows Server, Windows 11, or other Windows guests—particularly where nested virtualization is enabled for lab environments, CI infrastructure, Android emulators, nested Hyper-V testing, or virtual-machine appliances. Even there, the documented consequence is a kernel lock-debug warning during host-side vCPU setup, not compromise of the Windows guest or its host.
Fixed kernel versions are useful, but distribution packages remain the real check
Kernel.org’s CVE data marks these stable releases as containing the fix:
| Stable branch | First listed fixed release |
|---|---|
| Linux 5.10 | 5.10.261 |
| Linux 5.15 | 5.15.212 |
| Linux 6.1 | 6.1.178 |
| Linux 6.6 | 6.6.145 |
| Linux 6.12 | 6.12.96 |
| Linux 6.18 | 6.18.39 |
| Linux 7.1 | 7.1.4 |
Debian’s package records independently show the patch included in its
linux-signed-amd647.1.4 package alongside both the CR8-intercept relocation and the companion change to recompute CR8 interception on processor-priority updates. That confirms that, at least in one downstream package stream, distributors shipped the related changes as a group rather than treating this CVE patch as a stand-alone security repair.
Do not use
uname -ras the only decision point on enterprise distributions. Red Hat Enterprise Linux, SUSE Linux Enterprise, Ubuntu LTS, Debian stable, and cloud-provider kernels commonly backport a patch while retaining an older-looking upstream base version. Check the vendor kernel changelog, advisory metadata, or source package rather than assuming a
5.14,
5.15, or
6.1label is automatically vulnerable.
Administrators who maintain custom kernels should check whether the VMX change is present:
get_vmcs12()should be called only when
is_guest_mode(vcpu)is true in the CR8 interception update path. But the better operational answer is to take the current supported stable or distribution kernel update, because the CVE patch was delivered with related KVM correctness work.
Treat it as maintenance, not an emergency response
CVE-2026-64604 is a useful example of why a CVE identifier alone is not a severity rating. Kernel.org assigned the identifier to a real patch and supplied precise affected-release metadata. NIST has published the record. But the primary record also says there is no intended functional change, and the upstream patch discussion identifies the immediate problem as a syzkaller-detected lockdep false positive.
For Intel KVM hosts, install the available stable kernel update and reboot on the normal maintenance schedule. For security operations teams, do not claim that the CVE represents active exploitation, a guest escape, a Windows virtualization vulnerability, or a demonstrated denial-of-service condition; none of that appears in the public technical record.
The concrete payoff from updating is cleaner, correctly ordered KVM VMX handling around CR8-intercept maintenance and the related stale-intercept repair—not a newly disclosed critical hypervisor breach.