CVE-2026-46295
Received Received - Intake
Race Condition in KVM x86 IRR Scan Leading to Nested VM Warning

Publication date: 2026-06-08

Last updated on: 2026-06-08

Assigner: kernel.org

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.
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2026-06-08
Last Modified
2026-06-08
Generated
2026-06-09
AI Q&A
2026-06-08
EPSS Evaluated
N/A
NVD
CVE-2026-46295
EUVD
EUVD-2026-35161
Affected Vendors & Products
Currently, no data is known.
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-UNKNOWN
Attack-Flow Graph
AI Quick Actions
Instant insights powered by AI
Executive Summary

This vulnerability exists in the Linux kernel's KVM (Kernel-based Virtual Machine) subsystem for x86 architectures. It involves a race condition between two operations related to interrupt handling in nested virtual machines. Specifically, when the posted interrupt request (PIR) is empty but the posted interrupt descriptor (PID.ON) is set, the system incorrectly skips scanning the Interrupt Request Register (IRR). This leads to a spurious warning message and unnecessary VM-Enter/VM-Exit cycles, although the interrupt itself is not lost.

The root cause is a timing issue between the sender vCPU setting interrupt bits and the target vCPU synchronizing these bits. The fix involves falling back to a different method to correctly report the highest pending interrupt even when PIR is empty but PID.ON is set.

Impact Analysis

This vulnerability can cause spurious warning messages and unnecessary performance overhead due to wasted L2 VM-Enter and VM-Exit cycles in nested virtual machine environments. While it does not cause loss of interrupts or direct functional failures, the inefficiency may degrade performance in systems heavily relying on nested virtualization.

Detection Guidance

This vulnerability manifests as a spurious WARNING message in the Linux kernel logs related to KVM nested virtualization. Specifically, the warning appears in vmx_check_nested_events() when there is a race condition between vmx_sync_pir_to_irr() and __vmx_deliver_posted_interrupt().

To detect this vulnerability on your system, you should monitor the kernel logs for the following warning message:

  • WARNING: CPU: <cpu_number> PID: <pid> at arch/x86/kvm/vmx/nested.c:4449 vmx_check_nested_events+0x6bf/0x6e0 [kvm_intel]

You can use the following command to search for this warning in your kernel logs:

  • dmesg | grep 'vmx_check_nested_events'
  • journalctl -k | grep 'vmx_check_nested_events'

Since this is a kernel-level issue related to KVM nested virtualization, monitoring these logs is the primary method to detect the presence of this issue.

Mitigation Strategies

The vulnerability is caused by a race condition in the KVM nested virtualization code path. Immediate mitigation steps include:

  • Update your Linux kernel to a version where this issue is resolved, as the fix involves changes to the KVM APIC interrupt handling logic.
  • If updating the kernel is not immediately possible, monitor kernel logs for the warning to assess the impact and consider reducing nested virtualization workloads or disabling nested virtualization if feasible.
  • Avoid running nested VM stress tests or workloads that heavily rely on posted interrupts until the patch is applied.

Since the issue causes spurious warnings and wasted VM-Enter/VM-Exit cycles but does not cause interrupt loss, prioritizing kernel updates is the most effective mitigation.

Chat Assistant
Ask questions about this CVE
Hi! I’m here to help you understand CVE-2026-46295. Ask me anything about the vulnerability, its impact, or mitigation strategies.
0/70
EPSS Chart