CVE-2026-64513General

LOW

Signal is active with 1 mentions in latest observed window

Immediate actions

  • Patch affected systems immediately

Recommended action window: Monitor and triage in normal cycle

NVD description

In the Linux kernel, the following vulnerability has been resolved: KVM: x86: Unconditionally recompute CR8 intercept on PPR update The TPR_THRESHOLD field in the VMCS is used by VMX to induce VM exits when the guest's virtual TPR falls under the specified threshold, allowing KVM to inject previously masked interrupts. KVM handles these VM exits in handle_tpr_below_threshold(). Commit eb90f3417a0c ("KVM: vmx: speed up TPR below threshold vmexits") optimized this function by calling apic_update_ppr() instead of raising KVM_REQ_EVENT. apic_update_ppr() then raises KVM_REQ_EVENT if there is a pending, deliverable interrupt. However, if there are no new interrupts pending, apic_update_ppr() does not issue the request. Thus, kvm_lapic_update_cr8_intercept() and vmx_update_cr8_intercept() are not called before VM entry, which results in a high, stale TPR_THRESHOLD. This is problematic due to the following sentence in 28.2.1.1 "VM-Execution Control Fields" in the SDM: The following check is performed if the “use TPR shadow” VM-execution control is 1 and the “virtualize APIC accesses” and “virtual-interrupt delivery” VM-execution controls are both 0: the value of bits 3:0 of the TPR threshold VM-execution control field should not be greater than the value of bits 7:4 of VTPR. This error condition is typically not observed when KVM runs on a bare metal system because modern processors support APICv, which enables virtual-interrupt delivery, and which KVM uses when possible. This causes the processor to no longer generate TPR-below-threshold exits and to no longer check TPR_THRESHOLD on entry. However, when running on older platforms, or under nested virtualization on a hypervisor that does not support virtual-interrupt delivery and enforces this check (like Hyper-V) this can cause a VM entry failure with hardware error 0x7, as seen in [1]. Call kvm_lapic_update_cr8_intercept() if apic_update_ppr() does not find a deliverable interrupt (and thus does not raise KVM_REQ_EVENT). Remove calls to kvm_lapic_update_cr8_intercept() on paths that end up in apic_update_ppr(), as they now become redundant. This ensures that any path that updates the guest's PPR also figures out if KVM needs to wait for a TPR change (using TPR_THRESHOLD on VMX or CR8 intercepts on SVM).

0.5/ 10 priority

Sources & remediation

Priority

LOW

Exploitation

NONE

PoC

NONE

Patch

AVAILABLE

Momentum

STABLE

Threat summary

  • Patch or workaround signal is available
  • 4 mentions across 2 observed days
  • Momentum state: stable

What's happening

  • Patch or workaround mentioned in 1 signal
  • Technical details provided in 3 signals
  • General: 3 classified signals
  • Peaked 1d ago at 3 mentions (2026-07-25); latest day: 1
  • 4 total mentions across 2 days

Deep dive

Activity timeline4 mentions / 2d
01223Mentions · 2026-07-25: 3Mentions · 2026-08-11: 1Patch / Workaround · 2026-08-11: 1Technical Details · 2026-07-25: 2Technical Details · 2026-08-11: 107-2508-11
Signal classification2 categories
General
375.0%
Patch
125.0%
Referenced assets4 URLs
Classification over time
DateTotalLabels
2026-07-253
General3
2026-08-111
Patch1
Full discourse4 posts
  • Windows Forum@windowsforum
    Patch

    🐧 CVE-2026-64513 can break Linux KVM VM entry in nested Hyper-V setups. Not a Windows flaw—just another reminder to patch the Linux host before virtualization gets theatrical. https://windowsforum.com/security-alerts.84/cve-2026-64513-patch-linux-kvm-vm-entry-failures-on-hyper-v.442318/?utm_source=x&utm_medium=social&utm_campaign=news_node84 #NestedVirtualization #LinuxKvm #Cve202664513 #HyperV https://t.co/pbIRbykIyW

    Post summary

    The tweet highlights CVE-2026‑64513, a Linux KVM VM entry vulnerability in nested Hyper‑V, and urges patching of the Linux host, with no PoC, exploit code, or evidence of active exploitation.

    0000048
    1.3K followersView on X
  • Infoflowcloud@infoflowcloud
    General

    🚨*CVE* CVE-2026-64513 In the Linux kernel, the following vulnerability has been resolved: KVM: x86: Unconditionally recompute CR8 intercept on PPR update The TPR_THRESHOLD field in the V… https://www.cve.org/CVERecord?id=CVE-2026-64513 ----- Traducción: CVE-2026-64513 En … http://infoflow.cloud`

    Post summary

    The post notes that CVE‑2026‑64513 in the Linux kernel has been resolved and gives some technical details, but offers no proof of concept, exploit code, active exploitation claims, or explicit patch information.

    0000021
    95 followersView on X
  • CVE@CVEnew
    General

    CVE-2026-64513 In the Linux kernel, the following vulnerability has been resolved: KVM: x86: Unconditionally recompute CR8 intercept on PPR update The TPR_THRESHOLD field in the V… https://www.cve.org/CVERecord?id=CVE-2026-64513

    Post summary

    The text provides a brief CVE record for CVE‑2026‑64513, noting that a bug in the Linux kernel KVM module has been resolved and includes a concise technical description, but it offers no exploit details, patch instructions, or evidence of active exploitation.

    00000814
    57.9K followersView on X
  • Vulmon Vulnerability Feed@VulmonFeeds
    General

    CVE-2026-64513 In the Linux kernel, the following vulnerability has been resolved: KVM https://vulmon.com/vulnerabilitydetails?qid=CVE-2026-64513

    Post summary

    The brief note confirms that CVE‑2026‑64513, affecting KVM in the Linux kernel, has been resolved, but provides no further technical or patch details.

    0000098
    4.1K followersView on X

Explore more