CVE-2026-74517: KVM: x86: Cancel delayed I/O APIC EOI handling before destroying vCPUs
- Is it exploited?
Not on CISA's list. CISA has not added it to the Known Exploited Vulnerabilities catalog as of . If CISA adds it, this page shows it as known exploited.
- How likely is exploitation in the next 30 days?
- 0.1%
EPSS score, percentile 3.1 of all scored records. A probability estimated by FIRST, not a report of exploitation.
- How severe?
- 9.3 Critical
CVSS v3.1 base score, given by the CNA
- What should I do?
CISA has set no required action, because the vulnerability is not in KEV.
The CVE record links no vendor advisory, patch or mitigation.
- Which versions are affected?
Affected
- from 6.12.41 to before 6.12.105
- 6.14
Unaffected before 6.14; 6.12.105; 6.18.46; 7.1.8; 7.2
Source: CISA KEV 2026.10.28, as of ; FIRST EPSS, as of ; CVE List, as of . About the data.
What to do
Advisories and patches
The CVE record links no vendor advisory, patch or mitigation.
This summary is based on the CVE record as of . Check the vendor's advisory before you act: affected versions and fixes can change.
Affected products and versions
As listed in the CVE record.
| Status | Versions |
|---|---|
| Affected | from c60f5156e62d to before 69d040448067 |
| Affected | from 17bcd7144263 to before 5f0a99ea7212 |
| Affected | from 17bcd7144263 to before ed56a6b58222 |
| Affected | from 17bcd7144263 to before 9910e835580f |
| Affected | from 6.12.41 to before 6.12.105 |
Versions not listed are: unaffected.
| Status | Versions |
|---|---|
| Affected | 6.14 |
| Unaffected | before 6.14 |
| Unaffected | 6.12.105 |
| Unaffected | 6.18.46 |
| Unaffected | 7.1.8 |
| Unaffected | 7.2 |
Versions not listed are: affected.
Versions the record lists as unaffected: 6.12.105, 6.18.46, 7.1.8, 7.2.
Source: CVE List, as of . About the data.
About this vulnerability
In the Linux kernel, the following vulnerability has been resolved: KVM: x86: Cancel delayed I/O APIC EOI handling before destroying vCPUs Cancel (and flush) the I/O APIC's delayed EOI handling work during the "pre VM destroy" phase, before vCPUs are destroyed, as processing the EOI broadcast will inject another IRQ if the line is asserted, i.e. will try to deliver an IRQ to the target vCPU(s).…
Summary: CVE record, as of .
- CISA has not added CVE-2026-74517 to its Known Exploited Vulnerabilities (KEV) catalog, as of 28 Oct 2026.
- The CVE record was published on 15 Aug 2026.
- The CVE record carries a CVSS v3.1 base score of 9.3 (Critical), given by its CNA.
- FIRST's EPSS model puts the probability of exploitation in the next 30 days at 0.1% (percentile 3.1), as of 29 Oct 2026. EPSS is a statistical estimate, not a report of exploitation.
- CISA's SSVC assessment in the CVE record: exploitation none, automatable no, technical impact total.
Source: CISA KEV 2026.10.28, as of ; CVE List, as of ; FIRST EPSS, as of . About the data.
Description
KVM: x86: Cancel delayed I/O APIC EOI handling before destroying vCPUs
In the Linux kernel, the following vulnerability has been resolved: KVM: x86: Cancel delayed I/O APIC EOI handling before destroying vCPUs Cancel (and flush) the I/O APIC's delayed EOI handling work during the "pre VM destroy" phase, before vCPUs are destroyed, as processing the EOI broadcast will inject another IRQ if the line is asserted, i.e. will try to deliver an IRQ to the target vCPU(s). Canceling the work after vCPUs are destroyed leads to UAF if the delayed work is processed after vCPUs are destroyed. BUG: KASAN: slab-use-after-free in __kvm_irq_delivery_to_apic_fast+0x9bf/0xa20 arch/x86/kvm/lapic.c:1250 Read of size 8 at addr ffff8880499abea0 by task kworker/1:2/1218 CPU: 1 UID: 0 PID: 1218 Comm: kworker/1:2 Not tainted 7.1.0-rc7 #5 PREEMPT(lazy) Hardware name: QEMU Ubuntu 25.10 PC v2 (i440FX + PIIX, + 10.1 machine, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Workqueue: events kvm_ioapic_eoi_inject_work Call Trace: <TASK> __dump_stack lib/dump_stack.c:94 dump_stack_lvl+0x100/0x190 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 print_report+0x139/0x4ad mm/kasan/report.c:482 kasan_report+0xe4/0x1d0 mm/kasan/report.c:595 __kvm_irq_delivery_to_apic_fast+0x9bf/0xa20 arch/x86/kvm/lapic.c:1250 __kvm_irq_delivery_to_apic+0xd8/0xbf0 arch/x86/kvm/lapic.c:1345 kvm_irq_delivery_to_apic arch/x86/kvm/lapic.h:129 ioapic_service+0x308/0x590 arch/x86/kvm/ioapic.c:492 kvm_ioapic_eoi_inject_work+0x13c/0x190 arch/x86/kvm/ioapic.c:532 process_one_work+0xa59/0x19a0 kernel/workqueue.c:3314 process_scheduled_works kernel/workqueue.c:3397 worker_thread+0x5eb/0xe50 kernel/workqueue.c:3478 kthread+0x370/0x450 kernel/kthread.c:436 ret_from_fork+0x72b/0xd30 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 </TASK> Note, the VM is unreachable once kvm_destroy_vm() starts, and scheduling new work via kvm_ioapic_send_eoi() can only be done via KVM_RUN, i.e. requires a live vCPU. Alternatively, KVM could simply destroy the I/O APIC during the "pre" phase of VM destruction, but that gets more than a bit sketchy as KVM expects the I/O APIC to exist if ioapic_in_kernel() is true, and nested virtualization in particular has a bad habit of touching VM-scope state during vCPU destruction. E.g. attempting to free the PIC during the pre phase would lead to a NULL pointer dereference in kvm_cpu_has_extint(), and it's not hard to imagine the I/O APIC having a similar flaw.
Source: CVE List, as of . About the data.
Timeline
| Date | Event |
|---|---|
| CVE record published | |
| CVE record last updated |
Known exploited Linux vulnerabilities
- CVE-2026-46300: Linux Kernel Missing Initialization of a Variable Vulnerability
- CVE-2025-39682: Linux Kernel Improper Check for Unusual or Exceptional Conditions Vulnerability
- CVE-2025-39964: Linux Kernel Race Condition Vulnerability
- CVE-2026-53266: Linux Kernel Out-of-Bounds Write Vulnerability
- CVE-2026-53362: Linux Kernel Unspecified Vulnerability