CVE-2026-46295: KVM: x86: Do IRR scan in __kvm_apic_update_irr even if PIR is empty
Vulnerability summary
CVE-2026-46295 is a medium (CVSS 5.5) vulnerability in linux. EPSS estimates a 0.11% chance of exploitation in the next 30 days, higher than 1.3% of scored vulnerabilities.
Not severe (CVSS 5.5, local access); no exploitation reported by the 5 checked sources
Source freshness unavailable
How is this decided?Advisory lineage
Upstream 0 · Downstream 12 · Related 12Timeline
- 08-06-2026PublishedVulnerability first disclosed.
- 14-06-2026Last modifiedVulnerability information updated.
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 metrics
3 scores · 3 sources · 1 version- OSV · UbuntuEcosystem advisory · calculated5.5MediumCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
- OSV · DebianEcosystem advisory · calculated5.5MediumCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
EPSS trend
Probability
0.11%
Chance of exploitation in the next 30 days
Percentile
1%
Versus all other CVEs
30-day change
Decrease -0.05 pp
From 0.16% on 04-10-2026
Known exploited
Compare KEV catalogs
CISA KEVNot in the CISA KEV catalog.
ENISA CNWNot in the ENISA CNW catalog.
CIRCLNot in the CIRCL catalog.
Public exploits
0 foundNo public exploits indexed.
Weaknesses
CWE · root causeNo weakness data has been published for this record.
Affected systems
Known conditions: local access, low-privilege account, no user interaction (CVSS vector). Other conditions: not stated in public data.
Ubuntu115 products
- linuxAll versions (No fix recorded) | < 7.0.0-28.28
- linux-allwinner-5.19All versions (No fix recorded)
- linux-awsAll versions (No fix recorded) | < 7.0.0-1009.9
- linux-aws-5.0All versions (No fix recorded)
- linux-aws-5.11All versions (No fix recorded)
Linux2 products
- linux≥ b41f8638b9d30fbe045b4ef83ff4136c56a57397, < bb1703949dcaa9a49c338dee075f659f4634214d | ≥ b41f8638b9d30fbe045b4ef83ff4136c56a57397, < 4b6b06a8b12bfd95f9015074b1430c1480908073 | ≥ b41f8638b9d30fbe045b4ef83ff4136c56a57397, < 33fd0ccd2590b470b65adcca288615ad3b5e3e06 | 6.16
- linux_kernel≥ 6.16, < 6.18.30 | ≥ 6.19, < 7.0.7 | 7.1:rc1 | 7.1:rc2
Debian1 product
- linux< 7.0.7-1
3 vendors · 118 products
