CVE-2026-64513

What it actually does

This Linux kernel KVM x86 flaw can cause VM entry failure when KVM uses VMX TPR shadowing without virtual-interrupt delivery, particularly on older Intel platforms or in nested virtualization environments such as KVM running under a hypervisor that enforces the TPR threshold consistency check. A stale VMCS TPR_THRESHOLD value may remain after guest PPR/TPR state changes when no deliverable interrupt is pending, causing the processor to reject VM entry with a hardware error such as 0x7. The primary impact is denial of service for affected virtual machines rather than code execution or data disclosure.

Why it matters to the business

The practical risk is unexpected virtual machine outages or instability on affected Linux virtualization hosts, especially in nested virtualization, lab, CI/CD, cloud-hosting, or legacy hardware environments. Because this issue is not in CISA KEV, has very low EPSS, and has no known mature exploit activity, it is lower urgency than actively exploited vulnerabilities; however, organizations relying on KVM availability should still patch during normal kernel maintenance windows to prevent avoidable guest downtime.

How an attack unfolds

An attacker would need the ability to run code inside a guest VM on an affected KVM host or nested KVM stack. By exercising guest APIC/TPR behavior in a way that changes the guest processor priority state without creating a deliverable pending interrupt, the guest can cause KVM to retain a stale TPR_THRESHOLD value. On a subsequent VM entry, processors or parent hypervisors that enforce the VMX consistency check may reject the entry because the TPR threshold is greater than the virtual TPR value. The result is a VM entry failure and loss of availability for the affected guest vCPU or VM. This is most plausible where APICv or virtual-interrupt delivery is unavailable, disabled, or not exposed by the parent hypervisor.

How to fix it

Update the Linux kernel to a version that includes the KVM x86 fix that unconditionally recomputes the CR8/TPR intercept when PPR is updated. If vendor package versions are not yet listed, obtain the fixed kernel from the relevant Linux distribution or kernel vendor security advisory and reboot hosts into the patched kernel. As interim mitigations, avoid running untrusted nested virtualization workloads on affected hosts, prefer hardware and configurations that support APICv/virtual-interrupt delivery where available, and consider disabling or restricting nested virtualization for tenants or workloads that do not require it.

How to confirm the fix worked

Confirm the running kernel includes the upstream or vendor backport for the KVM x86 change that recomputes CR8 intercepts on PPR updates. Validate by checking the active kernel version after reboot, reviewing the distribution security advisory or changelog for the KVM x86 fix, and ensuring all virtualization hosts have actually booted into the fixed kernel rather than only installing the package. In environments where the issue was reproducible, rerun the nested virtualization or guest workload that previously produced VM-entry hardware error 0x7 and confirm the VM no longer fails to enter.

Typical attack path

1. Gain the ability to execute code inside a guest VM on a Linux KVM host or nested virtualization stack.
2. Run workload or crafted guest code that manipulates local APIC task-priority behavior and causes PPR/TPR transitions.
3. Trigger a path where KVM updates PPR but does not recompute the CR8/TPR intercept because no deliverable interrupt is pending.
4. Cause KVM to attempt VM entry with a stale, invalid TPR_THRESHOLD value.
5. Induce VM entry failure, leading to guest vCPU failure, VM instability, or denial of service.

How to detect it

Review host-side logs for evidence of prior VM entry failures or guest vCPU termination. Primary sources include kernel logs from dmesg or journald, libvirt logs, QEMU/KVM logs, host monitoring alerts for VM crashes, and parent-hypervisor logs in nested virtualization deployments. Look for messages indicating KVM VM-entry failure, VMX hardware error 0x7, unexpected guest shutdowns, repeated vCPU failures, or errors involving TPR threshold, CR8 intercept, VMCS, APIC, or APICv/virtual-interrupt delivery. Because this issue does not provide a unique remote exploitation signature, detection should focus on correlating these errors with guest workloads that manipulate APIC/interrupt priority state or with nested virtualization activity. Absence of these logs does not prove absence of exposure; many systems may be vulnerable but never hit the required hardware or configuration path.

• hardware error 0x7
• VM-entry failure
• VM entry failure
• KVM: entry failed
• kvm: entry failed
• VMX: entry failed
• vmx: entry failed
• TPR_THRESHOLD
• TPR threshold
• tpr below threshold
• handle_tpr_below_threshold
• CR8 intercept
• kvm_lapic_update_cr8_intercept
• vmx_update_cr8_intercept
• apic_update_ppr
• virtual-interrupt delivery
• APICv
• VMCS

What your security team should do

• Inventory Linux systems acting as KVM hypervisors, especially nested virtualization hosts, CI runners, lab hypervisors, and older Intel systems where APICv or virtual-interrupt delivery may not be available.
• Patch affected virtualization hosts through the normal kernel update process and reboot them into the fixed kernel.
• Prioritize hosts that run untrusted guest workloads or support nested virtualization, even though current public exploitation probability is low.
• Temporarily restrict nested virtualization or untrusted guest access on systems that cannot be patched promptly.
• Monitor kernel, libvirt, QEMU, and hypervisor logs for VM-entry failures, hardware error 0x7, unexplained guest vCPU failures, and repeated VM crashes.
• Document whether APICv/virtual-interrupt delivery is available and enabled on production virtualization platforms to understand exposure.