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.
Published: 2026-06-08
Score: 5.5 Medium
EPSS: < 1% Very Low
KEV: No
Impact: n/a
Action: n/a
AI Analysis

Impact

A race exists between the VMX synchronization of the pending interrupt register (PIR) and the delivery of posted interrupts. The sender sets two atomic bits, but they are not combined into a single transaction, allowing the target virtual CPU to clear and harvest a now‑empty PIR while the PID.ON bit is still set. This bug causes the kernel to compute an incorrect maximum IRR, emit an awkward warning, and incur an unnecessary L2 VM‑Enter/VM‑Exit transition. No data loss occurs, but the extra cycles can degrade performance under a heavily loaded nested VM program, and the warning generates noise in the log system. The weakness aligns with CWE-821.

Affected Systems

Linux kernel hosts running KVM on x86 architectures with nested virtualization. The flaw affects any configuration that enables nested virtualization. Specific kernel releases affected are not listed; the bug was fixed in the commit 33fd0ccd referenced in the data. Applications using older kernels that run nested VMs may experience spurious WARN messages and a slight performance hit.

Risk and Exploitability

There is no publicly disclosed exploitation vector. The EPSS score is not available and the vulnerability is not in the CISA KEV catalog. The CVSS score is 5.5. An attacker would need to run a nested VM under heavy IPI traffic to trigger the race, making it unlikely to be widely exploitable. The impact is limited to performance degradation and noisy logs rather than data loss or confidentiality compromise.

Generated by OpenCVE AI on June 9, 2026 at 03:39 UTC.

Remediation

No vendor fix or workaround currently provided.

OpenCVE Recommended Actions

  • Apply the kernel patch that includes commit 33fd0ccd or any later kernel release that incorporates this bug fix
  • If the kernel patch cannot be applied immediately and nested virtualization is not required for workloads, disable nested KVM by setting kvm.allow_nested=0 or equivalent
  • Persistently monitor vm‑entry/exit logs for the WARN pattern mentioned in the description and consider throttling IPI traffic or adjusting VM scheduling to reduce contention

Generated by OpenCVE AI on June 9, 2026 at 03:39 UTC.

Tracking

Sign in to view the affected projects.

Advisories

No advisories yet.

History

Tue, 09 Jun 2026 02:15:00 +0000

Type Values Removed Values Added
Weaknesses CWE-617

Tue, 09 Jun 2026 00:15:00 +0000

Type Values Removed Values Added
Weaknesses CWE-821
References
Metrics threat_severity

None

cvssV3_1

{'score': 5.5, 'vector': 'CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H'}

threat_severity

Moderate


Mon, 08 Jun 2026 19:30:00 +0000

Type Values Removed Values Added
Weaknesses CWE-617

Mon, 08 Jun 2026 17:00:00 +0000

Type Values Removed Values Added
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.
Title KVM: x86: Do IRR scan in __kvm_apic_update_irr even if PIR is empty
First Time appeared Linux
Linux linux Kernel
CPEs cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
Vendors & Products Linux
Linux linux Kernel
References

Subscriptions

Linux Linux Kernel
cve-icon MITRE

Status: PUBLISHED

Assigner: Linux

Published:

Updated: 2026-06-08T15:46:22.494Z

Reserved: 2026-05-13T15:03:33.110Z

Link: CVE-2026-46295

cve-icon Vulnrichment

No data.

cve-icon NVD

Status : Received

Published: 2026-06-08T17:16:47.913

Modified: 2026-06-08T17:16:47.913

Link: CVE-2026-46295

cve-icon Redhat

Severity : Moderate

Publid Date: 2026-06-08T00:00:00Z

Links: CVE-2026-46295 - Bugzilla

cve-icon OpenCVE Enrichment

Updated: 2026-06-09T03:45:26Z

Weaknesses