CVE-2026-64513: Patch Linux KVM VM Entry Failures on Hyper-V

The advisory comes from the Linux kernel project, and NVD’s record identifies fixed upstream releases as Linux 6.18.39, Linux 7.1.4, and the 7.2-rc1 development line. Debian’s security tracker separately marks its unstable kernel packages fixed and lists older supported Debian kernel tracks as vulnerable pending backports. The important operational detail is that distributors routinely backport kernel fixes, so a host’s

version alone is not sufficient evidence that it remains exposed.

There is also a date discrepancy worth clearing up. The NVD page was inaccessible through Cloudflare when this item was submitted on August 11, 2026, but NVD’s own record says CVE-2026-64513 was received from kernel.org and published on July 25, 2026, with its last modification also dated July 25. This is not a newly created August 11 CVE; it is a July kernel CVE whose NVD page was temporarily unavailable.

A stale interrupt threshold can stop a VM before it runs​

The defect sits in KVM’s Local APIC emulation, specifically its management of CR8, the x86 task-priority register, and the processor-priority register, or PPR. These registers participate in deciding which interrupts a virtual CPU can receive. KVM uses VMX’s

control to request a VM exit when a guest lowers its interrupt priority enough that an interrupt previously masked by priority can now be delivered.

A prior KVM optimization, introduced by commit

, changed the path used after one of those threshold events. Instead of always marking an event for processing before the guest resumed, the code called

. That function raises KVM’s event request only if it finds an interrupt that is immediately deliverable.

That conditional shortcut is the failure point. When there is no newly deliverable interrupt, the event request is skipped—and KVM fails to recompute the CR8 interception state before the next VM entry. The result is a stale, excessively high

value in the VMCS, the control structure Intel processors use to run virtual machines.

Intel’s VMX consistency rules reject that mismatch in configurations using TPR shadowing without virtual interrupt delivery. The observable consequence is a failed attempt to enter the guest, reported as hardware error 0x7. This is a guest availability and reliability failure: a virtual CPU cannot resume, rather than a demonstrated route to execute host code, read cross-VM memory, or escape a guest.

That distinction is important because CVE labels often cause every kernel flaw to be treated as a conventional compromise scenario. NVD has not assigned a CVSS score or a CWE classification to CVE-2026-64513 as of August 11. The kernel advisory and the patch discussion describe a VM-entry consistency failure; they do not describe a privilege-escalation exploit, data disclosure, or a known exploitation campaign.

Hyper-V is specifically named in the failure conditions​

The kernel patch series, authored by Carlos López and queued by KVM maintainer Paolo Bonzini, says the faulty condition is usually invisible on modern bare-metal systems. The reason is APICv, Intel’s hardware support for virtualizing APIC interrupt handling. When KVM can use APICv’s virtual-interrupt delivery, the processor no longer generates the problematic TPR-below-threshold exits and does not apply the same VM-entry threshold check.

The affected corner is therefore narrower than “all KVM hosts.” It becomes relevant on older platforms that do not expose the needed APICv support and, most notably for Windows-focused administrators, in nested virtualization where the outer hypervisor does not offer virtual-interrupt delivery while enforcing the VMX consistency rule.

The patch documentation calls out Hyper-V as an example of that outer hypervisor. In practical terms, the topology looks like this:

• Windows Server or Windows 11 runs Hyper-V.
• Hyper-V hosts a Linux virtual machine.
• That Linux VM is configured to run KVM virtual machines of its own.
• The nested KVM layer encounters the stale TPR threshold state and the outer platform rejects the next VM entry.

A workstation that runs Hyper-V VMs but never loads or uses Linux KVM is not affected. Nor is a conventional Linux KVM server automatically vulnerable simply because its kernel version predates the fixed upstream releases; modern bare-metal Intel systems using APICv may never exercise the bad path. But “may not trigger” is not a remediation strategy for infrastructure that depends on nested guest availability.

For Windows admins, the consequence is especially easy to misdiagnose. A failure may appear in the Linux guest as a KVM launch, resume, or virtual-CPU problem even though the immediate enforcement happens at the Hyper-V-backed VMX boundary. Reinstalling guest images, changing ordinary VM configuration, or patching the Windows host alone does not correct the stale state in the Linux KVM code.

The actual fix is small, but it follows every PPR update​

The final patch is compact: when

does not find a deliverable interrupt and therefore does not queue the normal KVM event request, KVM now explicitly calls

. That forces KVM to recalculate whether it should wait for a TPR change before the virtual CPU re-enters the guest.

The patch also removes redundant calls from other paths whose PPR updates already flow through that helper. This is more than code cleanup. The corrected design makes PPR updates consistently refresh the related interrupt-interception state, regardless of whether an interrupt happens to be pending at that moment.

The initial proposed repair was narrower: it restored an unconditional

request after a TPR-below-threshold VM exit. KVM maintainers pushed back because other PPR-update paths could theoretically carry the same stale-state problem. The accepted approach fixes the condition where it originates, in PPR handling, rather than relying on one caller to force an unrelated event-processing pass.

The final series included a companion VMX change after syzbot found a lockdep warning during virtual CPU creation. That companion adjustment retrieves nested VMCS state only when the virtual CPU is actually in guest mode. It is described as having no intended functional change, but its presence matters for operators building or consuming kernels with the fix: the stable update contains a two-patch series, not merely a one-line KVM change.

Fixed upstream does not mean every supported distribution is covered​

NVD’s kernel.org-supplied record marks kernels from Linux 4.11 forward as affected until the relevant fix commits. That range traces the issue back to the 2017 optimization, not to a newly introduced regression in 2026. In other words, long-term kernel branches can carry the defect even though the CVE was only published on July 25, 2026.

The upstream fixed points are clear:

• Linux 6.18.39 contains the stable-branch fix.
• Linux 7.1.4 contains the stable-branch fix.
• Linux 7.2-rc1 contains the mainline fix.

Debian provides a useful example of why package-level verification is required. Its tracker lists Debian sid as fixed in

7.1.5-1 and identifies 7.1.4-1 as the upstream fixed package baseline, while Debian releases carrying 5.10, 6.1, 6.12, and 7.1.3 kernel packages remain listed as vulnerable. That does not mean every distribution with a 5.x or 6.x kernel is exposed today; Red Hat, SUSE, Ubuntu, Azure Linux, and other vendors can backport the patch without adopting a newer upstream version number.

Microsoft’s Azure Linux repositories include kernel

, a vendor kernel whose version number is far below the upstream 6.18.39 fix line. That is exactly why administrators should consult the distribution’s errata and changelog rather than treating upstream version thresholds as universal package guidance.

What administrators should do now​

First, identify Linux systems that are actually acting as KVM hosts. The relevant systems are not ordinary Linux VMs; they are systems where the

and Intel VMX KVM components are loaded and where QEMU, libvirt, OpenStack, Kubernetes virtualization stacks, or similar tooling launches nested guests.

Second, prioritize hosts that satisfy all three conditions: Intel VMX-backed KVM, nested virtualization, and an outer environment that may not expose virtual-interrupt delivery. Linux KVM guests hosted on Hyper-V belong near the top of that list. Older bare-metal Intel systems without APICv are the other clear priority.

Third, install the vendor kernel update that explicitly includes CVE-2026-64513 or the corresponding KVM stable backport, then reboot the Linux KVM host. A kernel package installation without a reboot leaves the running KVM module and its old interrupt-handling path in memory.

The concrete risk is not a broad Windows fleet emergency. It is a narrow but real nested-virtualization failure that can leave KVM guests unable to enter or resume on Hyper-V-backed Linux hosts. For organizations that run that stack, the remedy is available upstream and should be folded into the next kernel maintenance window rather than waiting for a Windows patch that will never arrive.