---
id: CVE-2026-46295
title: |-
  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 correc…
summary: |-
  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 correc…
severity: none
published: '2026-06-08'
updated: '2026-07-07'
source: NVD
sourceUrl: 'https://nvd.nist.gov/vuln/detail/CVE-2026-46295'
references:
  - url: 'https://git.kernel.org/stable/c/33fd0ccd2590b470b65adcca288615ad3b5e3e06'
    label: 416baaa9-dc9f-4396-8d5f-8c081fb06d67
  - url: 'https://git.kernel.org/stable/c/4b6b06a8b12bfd95f9015074b1430c1480908073'
    label: 416baaa9-dc9f-4396-8d5f-8c081fb06d67
  - url: 'https://git.kernel.org/stable/c/bb1703949dcaa9a49c338dee075f659f4634214d'
    label: 416baaa9-dc9f-4396-8d5f-8c081fb06d67
tags:
  - nvd
epss: 0.0016
epssPercentile: 0.04383
ingestedAt: '2026-07-07T18:42:24.308Z'
---

## Overview

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.

## Remediation

Refer to the linked advisories for vendor-supplied fixes and affected version ranges.