CVE-2026-46295

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: x86: Do IRR scan in __kvm_apic_update_irr even if PIR is empty<br /> <br /> Fall back to apic_find_highest_vector() when PID.ON is set but PIR<br /> turns out to be empty, to correctly report the highest pending interrupt<br /> from the existing IRR.<br /> <br /> In a nested VM stress test, the following WARNING fires in<br /> vmx_check_nested_events() when kvm_cpu_has_interrupt() reports a pending<br /> interrupt but the subsequent kvm_apic_has_interrupt() (which invokes<br /> vmx_sync_pir_to_irr() again) returns -1:<br /> <br /> WARNING: CPU: 99 PID: 57767 at arch/x86/kvm/vmx/nested.c:4449 vmx_check_nested_events+0x6bf/0x6e0 [kvm_intel]<br /> Call Trace:<br /> kvm_check_and_inject_events<br /> vcpu_enter_guest.constprop.0<br /> vcpu_run<br /> kvm_arch_vcpu_ioctl_run<br /> kvm_vcpu_ioctl<br /> __x64_sys_ioctl<br /> do_syscall_64<br /> entry_SYSCALL_64_after_hwframe<br /> <br /> The root cause is a race between vmx_sync_pir_to_irr() on the target vCPU<br /> and __vmx_deliver_posted_interrupt() on a sender vCPU. The sender<br /> performs two individually-atomic operations that are not a single<br /> transaction:<br /> <br /> 1. pi_test_and_set_pir(vector) -- sets the PIR bit<br /> 2. pi_test_and_set_on() -- sets PID.ON<br /> <br /> The following interleaving triggers the bug:<br /> <br /> Sender vCPU (IPI): Target vCPU (1st sync_pir_to_irr):<br /> B1: set PIR[vector]<br /> A1: pi_clear_on()<br /> A2: pi_harvest_pir() -&gt; sees B1 bit<br /> A3: xchg() -&gt; consumes bit, PIR=0<br /> (1st sync returns correct max_irr)<br /> B2: set PID.ON = 1<br /> <br /> Target vCPU (2nd sync_pir_to_irr):<br /> C1: pi_test_on() -&gt; TRUE (from B2)<br /> C2: pi_clear_on() -&gt; ON=0<br /> C3: pi_harvest_pir() -&gt; PIR empty<br /> C4: *max_irr = -1, early return<br /> IRR NOT SCANNED<br /> <br /> The interrupt is not lost (it resides in the IRR from the first sync and<br /> is recovered on the next vcpu_enter_guest() iteration), but the incorrect<br /> max_irr causes a spurious WARNING and a wasted L2 VM-Enter/VM-Exit cycle.