KVM: x86: Do IRR scan in __kvm_apic_update_irr even if PIR is empty
Summary
| CVE | CVE-2026-46295 |
|---|---|
| State | PUBLISHED |
| Assigner | Linux |
| Source Priority | CVE Program / NVD first with legacy fallback |
| Published | 2026-06-08 17:16:47 UTC |
| Updated | 2026-06-08 17:16:47 UTC |
| Description | In the Linux kernel, the following vulnerability has been resolved: KVM: x86: Do IRR scan in __kvm_apic_update_irr even if PIR is empty Fall back to apic_find_highest_vector() when PID.ON is set but PIR turns out to be empty, to correctly report the highest pending interrupt from the existing IRR. In a nested VM stress test, the following WARNING fires in vmx_check_nested_events() when kvm_cpu_has_interrupt() reports a pending interrupt but the subsequent kvm_apic_has_interrupt() (which invokes vmx_sync_pir_to_irr() again) returns -1: WARNING: CPU: 99 PID: 57767 at arch/x86/kvm/vmx/nested.c:4449 vmx_check_nested_events+0x6bf/0x6e0 [kvm_intel] Call Trace: kvm_check_and_inject_events vcpu_enter_guest.constprop.0 vcpu_run kvm_arch_vcpu_ioctl_run kvm_vcpu_ioctl __x64_sys_ioctl do_syscall_64 entry_SYSCALL_64_after_hwframe The root cause is a race between vmx_sync_pir_to_irr() on the target vCPU and __vmx_deliver_posted_interrupt() on a sender vCPU. The sender performs two individually-atomic operations that are not a single transaction: 1. pi_test_and_set_pir(vector) -- sets the PIR bit 2. pi_test_and_set_on() -- sets PID.ON The following interleaving triggers the bug: Sender vCPU (IPI): Target vCPU (1st sync_pir_to_irr): B1: set PIR[vector] A1: pi_clear_on() A2: pi_harvest_pir() -> sees B1 bit A3: xchg() -> consumes bit, PIR=0 (1st sync returns correct max_irr) B2: set PID.ON = 1 Target vCPU (2nd sync_pir_to_irr): C1: pi_test_on() -> TRUE (from B2) C2: pi_clear_on() -> ON=0 C3: pi_harvest_pir() -> PIR empty C4: *max_irr = -1, early return IRR NOT SCANNED The interrupt is not lost (it resides in the IRR from the first sync and is recovered on the next vcpu_enter_guest() iteration), but the incorrect max_irr causes a spurious WARNING and a wasted L2 VM-Enter/VM-Exit cycle. |
Risk And Classification
EPSS: 0.000220000 probability, percentile 0.063970000 (date 2026-06-14)
Vendor Declared Affected Products
| Source | Vendor | Product | Version | Platforms |
|---|---|---|---|---|
| CNA | Linux | Linux | affected b41f8638b9d30fbe045b4ef83ff4136c56a57397 bb1703949dcaa9a49c338dee075f659f4634214d git | Not specified |
| CNA | Linux | Linux | affected b41f8638b9d30fbe045b4ef83ff4136c56a57397 4b6b06a8b12bfd95f9015074b1430c1480908073 git | Not specified |
| CNA | Linux | Linux | affected b41f8638b9d30fbe045b4ef83ff4136c56a57397 33fd0ccd2590b470b65adcca288615ad3b5e3e06 git | Not specified |
| CNA | Linux | Linux | affected 6.16 | Not specified |
| CNA | Linux | Linux | unaffected 6.16 semver | Not specified |
| CNA | Linux | Linux | unaffected 6.18.30 6.18.* semver | Not specified |
| CNA | Linux | Linux | unaffected 7.0.7 7.0.* semver | Not specified |
| CNA | Linux | Linux | unaffected 7.1-rc3 * original_commit_for_fix | Not specified |
References
| Reference | Source | Link | Tags |
|---|---|---|---|
| git.kernel.org/stable/c/33fd0ccd2590b470b65adcca288615ad3b5e3e06 | 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | git.kernel.org | |
| git.kernel.org/stable/c/4b6b06a8b12bfd95f9015074b1430c1480908073 | 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | git.kernel.org | |
| git.kernel.org/stable/c/bb1703949dcaa9a49c338dee075f659f4634214d | 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | git.kernel.org | |
| CVE Program record | CVE.ORG | www.cve.org | canonical |
| NVD vulnerability detail | NVD | nvd.nist.gov | canonical, analysis |
No vendor comments have been submitted for this CVE.
There are currently no legacy QID mappings associated with this CVE.