CVE-2026-64513

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