PT-2026-47367 · Linux · Linux

Published

2026-06-08

·

Updated

2026-06-08

·

CVE-2026-46295

None

No severity ratings or metrics are available. When they are, we'll update the corresponding info on the page.
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.

Related Identifiers

CVE-2026-46295

Affected Products

Linux