CVE-2026-46295

What it actually does

This is a race condition in the Linux kernel KVM x86 posted-interrupt handling path. Under a specific interleaving between a sender vCPU delivering a posted interrupt and a target vCPU synchronizing posted interrupts into the local APIC interrupt request register, KVM can incorrectly report that no highest pending interrupt exists even though an interrupt is already present in the IRR. The interrupt is not lost, but the inconsistent state can trigger a kernel WARNING in the nested VMX event-checking path and causes a wasted nested VM entry/exit cycle. The primary technical impact is host kernel warning generation and virtualization instability; on systems configured to panic on kernel warnings, this could escalate to a host denial of service.

Why it matters to the business

Organizations running Linux KVM virtualization, especially with nested virtualization enabled or heavy VM interrupt activity, may experience hypervisor instability, noisy kernel warnings, degraded VM performance, or host crashes if kernel warnings are treated as fatal. Because EPSS is very low, the issue is not currently assessed as broadly exploited, but virtualization hosts are high-value infrastructure and should be patched during normal kernel maintenance windows, with higher priority for platforms offering nested virtualization or untrusted guest workloads.

How an attack unfolds

An attacker would need the ability to run code inside a guest VM, or otherwise influence guest activity, in a way that creates high-frequency inter-processor interrupts and nested VM entry/exit activity. By repeatedly stressing nested virtualization and interrupt delivery paths, the attacker attempts to trigger a timing window where one vCPU sets a posted interrupt bit, the target vCPU consumes it into the IRR, and then the sender sets the posted-interrupt ON flag afterward. During the next synchronization, KVM observes the ON flag but finds an empty posted-interrupt request bitmap, incorrectly returns no pending interrupt, and hits a WARNING in vmx_check_nested_events(). In most configurations this results in log noise and extra VM exit/entry work rather than direct privilege escalation. If the host is configured with panic_on_warn or similar hard-fail behavior, repeated triggering may crash the host and disrupt all workloads on it.

How to fix it

Apply a Linux kernel update that includes the KVM x86 fix for posted-interrupt IRR scanning in __kvm_apic_update_irr(). No exact fixed package versions were provided in the input, so use the fixed kernel packages from the relevant Linux distribution or vendor advisory. After updating, reboot virtualization hosts into the patched kernel and confirm KVM modules are reloaded from that kernel. Where immediate patching is not possible, reduce exposure by disabling nested virtualization for untrusted guests, limiting access to VMX/SVM nested virtualization features, avoiding panic_on_warn on production hypervisors where appropriate to operational policy, and monitoring for repeated KVM warning traces. These mitigations reduce impact but do not replace the kernel fix.

How to confirm the fix worked

Confirm the running kernel version includes the vendor backport or upstream fix for the KVM change that falls back to apic_find_highest_vector() when PID.ON is set but PIR is empty. Validate that hosts have been rebooted after kernel package installation, because replacing kernel packages alone does not patch the running kernel. Check loaded modules such as kvm_intel or kvm_amd are associated with the patched kernel. For functional validation, run controlled KVM or nested-virtualization stress tests and verify that the vmx_check_nested_events WARNING no longer appears in dmesg, journald, or kernel logs.

Typical attack path

1. Obtain the ability to run workloads inside a KVM guest, preferably where nested virtualization is enabled.
2. Start nested VM or vCPU stress workloads that generate frequent interrupts, IPIs, and VM entry/exit transitions.
3. Create contention between sender and target vCPUs so posted-interrupt PIR and PID.ON updates occur in the vulnerable interleaving.
4. Trigger the KVM nested VMX warning path when kvm_cpu_has_interrupt() and kvm_apic_has_interrupt() observe inconsistent interrupt state.
5. Repeat the condition to cause host log flooding, degraded virtualization performance, or a host crash if kernel warnings are configured to panic.

How to detect it

Look for evidence of kernel warnings and KVM nested VMX traces in host-level logs. Primary sources include dmesg, /var/log/kern.log, /var/log/messages, journald kernel facility logs, crash dump records, hypervisor monitoring alerts, and any centralized log collection that ingests kernel warnings. Search for WARNING traces pointing to vmx_check_nested_events(), kvm_check_and_inject_events(), vcpu_enter_guest(), kvm_arch_vcpu_ioctl_run(), kvm_vcpu_ioctl(), or kvm_intel. Correlate events with bursts of nested virtualization activity, high IPI rates, VM stress testing, or repeated VM entry/exit failures. Exploitation is difficult to distinguish from stress-induced triggering because the observable artifact is a kernel warning rather than a unique exploit payload. If host crashes occurred, inspect vmcore, kdump, pstore, and previous-boot journals for matching stack traces. There are no known public threat actors or ransomware campaigns associated with this issue in the provided data.

• WARNING: CPU:
• vmx_check_nested_events+0x6bf/0x6e0 [kvm_intel]
• arch/x86/kvm/vmx/nested.c:4449
• kvm_check_and_inject_events
• vcpu_enter_guest.constprop.0
• kvm_arch_vcpu_ioctl_run
• kvm_vcpu_ioctl
• __x64_sys_ioctl
• entry_SYSCALL_64_after_hwframe
• kvm_intel
• vmx_sync_pir_to_irr
• __vmx_deliver_posted_interrupt
• kvm_cpu_has_interrupt
• kvm_apic_has_interrupt
• PID.ON
• PIR empty
• highest pending interrupt
• panic_on_warn

What your security team should do

• Inventory Linux KVM hypervisors and identify systems with nested virtualization enabled or exposed to untrusted guest workloads.
• Prioritize kernel updates for KVM hosts that run multi-tenant workloads, nested virtualization, CI virtualization farms, or high-interrupt guest workloads.
• Schedule host reboots after applying patched kernel packages and verify the patched kernel is actually running.
• Temporarily disable nested virtualization for untrusted guests if patching must be delayed.
• Review kernel panic policy, especially panic_on_warn, to understand whether this warning can cause full host outages.
• Monitor kernel logs for KVM, VMX, APIC, and posted-interrupt warning traces that match this issue.
• Because this is not in CISA KEV and has very low EPSS, handle through risk-based patch management unless the environment heavily depends on nested virtualization.