{
  "affected": [
    {
      "ecosystem_specific": {
        "urgency": "not yet assigned"
      },
      "package": {
        "ecosystem": "Debian:14",
        "name": "linux"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "7.0.7-1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "details": "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() -\u003e sees B1 bit                                   A3: xchg() -\u003e 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() -\u003e TRUE (from B2)                                   C2: pi_clear_on() -\u003e ON=0                                   C3: pi_harvest_pir() -\u003e 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.",
  "id": "DEBIAN-CVE-2026-46295",
  "modified": "2026-09-14T16:47:32.387812340Z",
  "published": "2026-06-08T17:16:47.913Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://security-tracker.debian.org/tracker/CVE-2026-46295"
    }
  ],
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ],
  "upstream": [
    "CVE-2026-46295"
  ]
}