GHSA-Q4RX-HJ9C-J8VG
Vulnerability from github – Published: 2026-06-08 18:31 – Updated: 2026-06-08 18:31In 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:
- pi_test_and_set_pir(vector) -- sets the PIR bit
- 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.
{
"affected": [],
"aliases": [
"CVE-2026-46295"
],
"database_specific": {
"cwe_ids": [],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-06-08T17:16:47Z",
"severity": null
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nKVM: x86: Do IRR scan in __kvm_apic_update_irr even if PIR is empty\n\nFall back to apic_find_highest_vector() when PID.ON is set but PIR\nturns out to be empty, to correctly report the highest pending interrupt\nfrom the existing IRR.\n\nIn a nested VM stress test, the following WARNING fires in\nvmx_check_nested_events() when kvm_cpu_has_interrupt() reports a pending\ninterrupt but the subsequent kvm_apic_has_interrupt() (which invokes\nvmx_sync_pir_to_irr() again) returns -1:\n\n WARNING: CPU: 99 PID: 57767 at arch/x86/kvm/vmx/nested.c:4449 vmx_check_nested_events+0x6bf/0x6e0 [kvm_intel]\n Call Trace:\n kvm_check_and_inject_events\n vcpu_enter_guest.constprop.0\n vcpu_run\n kvm_arch_vcpu_ioctl_run\n kvm_vcpu_ioctl\n __x64_sys_ioctl\n do_syscall_64\n entry_SYSCALL_64_after_hwframe\n\nThe root cause is a race between vmx_sync_pir_to_irr() on the target vCPU\nand __vmx_deliver_posted_interrupt() on a sender vCPU. The sender\nperforms two individually-atomic operations that are not a single\ntransaction:\n\n 1. pi_test_and_set_pir(vector) -- sets the PIR bit\n 2. pi_test_and_set_on() -- sets PID.ON\n\nThe following interleaving triggers the bug:\n\n Sender vCPU (IPI): Target vCPU (1st sync_pir_to_irr):\n B1: set PIR[vector]\n A1: pi_clear_on()\n A2: pi_harvest_pir() -\u003e sees B1 bit\n A3: xchg() -\u003e consumes bit, PIR=0\n (1st sync returns correct max_irr)\n B2: set PID.ON = 1\n\n Target vCPU (2nd sync_pir_to_irr):\n C1: pi_test_on() -\u003e TRUE (from B2)\n C2: pi_clear_on() -\u003e ON=0\n C3: pi_harvest_pir() -\u003e PIR empty\n C4: *max_irr = -1, early return\n IRR NOT SCANNED\n\nThe interrupt is not lost (it resides in the IRR from the first sync and\nis recovered on the next vcpu_enter_guest() iteration), but the incorrect\nmax_irr causes a spurious WARNING and a wasted L2 VM-Enter/VM-Exit cycle.",
"id": "GHSA-q4rx-hj9c-j8vg",
"modified": "2026-06-08T18:31:52Z",
"published": "2026-06-08T18:31:52Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46295"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/33fd0ccd2590b470b65adcca288615ad3b5e3e06"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/4b6b06a8b12bfd95f9015074b1430c1480908073"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/bb1703949dcaa9a49c338dee075f659f4634214d"
}
],
"schema_version": "1.4.0",
"severity": []
}
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.