data built 2026-10-19T13:16:53Z

Look up another CVE · open CVE-2026-74517 in the interactive tracker

CVE-2026-74517

KVM: x86: Cancel delayed I/O APIC EOI handling before destroying vCPUs

9.3 EPSS 0.1% AV:L

Published 2026-08-15 (2 months ago) by the Linux kernel CNA. Subsystem arch/x86. Debian urgency: unimportant.

What to do, per Debian release

Debian's own status for CVE-2026-74517 in every release this site tracks, and what each one means in practice. Every status below is the one the Debian Security Team publishes for this CVE. source

ReleaseStatus VersionWhat this means
Debian 12bookwormnot affected6.1.190-1Nothing to do. bookworm never shipped the vulnerable code.
Debian 13trixiefixedDSA-6466-1 · 2026-08-25 · text6.12.105-1Update the kernel and reboot. DSA-6466-1 shipped the fix on 2026-08-25, in 6.12.105-1. A running kernel keeps the old code until the machine restarts.
Debian 14forkyfixed7.1.8-1Update the kernel and reboot. Fixed in 7.1.8-1. A running kernel keeps the old code until the machine restarts.
Debian unstablesidfixed7.1.8-1Update the kernel and reboot. Fixed in 7.1.8-1. A running kernel keeps the old code until the machine restarts.
Debian 12bookworm · linux-6.12fixedDLA-4788-1 · 2026-09-19 · text6.12.107-1~deb12u1Update the kernel and reboot. DLA-4788-1 shipped the fix on 2026-09-19, in 6.12.107-1~deb12u1. A running kernel keeps the old code until the machine restarts.

The vulnerability

What the bug is

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.

Where it lives

The fix touches these files. If the subsystem is one you do not use, the practical exposure is lower, though the package is still the vulnerable one.

arch/x86/kvm/x86.c

What this is
KERNEL VIRTUAL MACHINE FOR X86 (KVM/x86)MAINTAINERS section matched on arch/x86/kvm/ · kvm@vger.kernel.org · Supported
Kernel module
kvm

Check it on the machine

grep -wE 'CONFIG_KVM|CONFIG_KVM_X86' /boot/config-$(uname -r)

Reads the booted kernel's own configuration, on the machine and nowhere else. =y is built in, =m is a module, and an is not set line means the code is not there.

lsmod | grep -w kvm

Prints a line if that module is loaded right now, and nothing if it is not. One that is not loaded can still be loaded later by anything that needs it.

Show whether Debian builds this, per release

Debian builds this, but not on every flavour. At least one release below builds the code on some of its kernel flavours and not on others, so the answer depends on the architecture and flavour installed.

  • bookwormBnot built on arm64/rt/arm64, armhf/armmp, armhf/armmp-lpae, armhf/rt/armmp
  • trixieMnot built on arm64/arm64, arm64/arm64-16k, arm64/cloud-arm64, arm64/rt/arm64, armel/rpi, armhf/armmp, armhf/armmp-lpae, armhf/rt/armmp, ppc64el/powerpc64le, ppc64el/powerpc64le-64k, riscv64/riscv64, s390x/s390x
  • forky, sidMnot built on arm64/arm64, arm64/arm64-16k, arm64/cloud-arm64, arm64/rt-arm64, armhf/armmp, armhf/armmp-lpae, loong64/loong64, ppc64el/powerpc64le, ppc64el/powerpc64le-64k, riscv64/riscv64, s390x/s390x
  • bookworm · linux-6.12Mnot built on arm64/arm64, arm64/arm64-16k, arm64/cloud-arm64, arm64/rt/arm64, armhf/armmp, armhf/armmp-lpae, armhf/rt/armmp, ppc64el/powerpc64le, ppc64el/powerpc64le-64k
B
built in on some, a module on others, absent on the rest
M
a module where it is built at all; some flavours do not build it
Build switches
CONFIG_KVM, CONFIG_KVM_X86
Reads as
all on means the file is compiled; any one off means it is not.

From the configuration Debian publishes for every kernel flavour it builds. It covers only the architectures Debian ships a linux-config package for, and nothing about a kernel you built yourself. Debian's own status above stays authoritative about the source package.MAINTAINERS kbuild Makefiles Debian linux-config packages

Signals

Published
2026-08-15 (2 months ago)source
CVSS
9.3 critical
CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:Hsource recompute it
Attack vector
local (AV:L)source
EPSS
0.14%, higher than 2.8% of all CVEssource
CISA KEV
not listedthe KEV catalogue
Debian urgency
unimportantsource
Subsystem
arch/x86

Upstream fixes

The versions the CNA records as introducing and fixing this, and the commit for each. source

IntroducedFixed inCommit
6.12.416.12.10569d040448067
6.146.18.465f0a99ea7212
6.147.1.8ed56a6b58222
6.147.29910e835580f

Debian advisories

AdvisoryDateShipped toDebian
DLA-4788-12026-09-19bookworm 6.12.107-1~deb12u1tracker
DSA-6466-12026-08-25trixie 6.12.105-1tracker

Why the CNA scored it this way

Quoted from the kernel CNA's own scoring file, word for word. A highlighted metric carries the most severe value CVSS v3.1 defines for it, which is what pushes the score up. source

AV:LAttack vector, local
The vulnerable I/O APIC delayed-EOI workqueue path is reached from host-local KVM ioctls (KVM_CREATE_IRQCHIP/KVM_RUN) and vCPU MMIO/EOI handling during in-kernel irqchip operation; it is not exposed via any network-facing kernel service.
AC:LAttack complexity, low
The slab UAF is attacker-driven: a guest can trigger 10,000 level-triggered IOAPIC EOIs to schedule the delayed work, then immediately halt/exit so the VMM tears down the VM while that work is still pending, controlling both sides of the race.
PR:NPrivileges required, none
A malicious KVM guest on cloud or hosted x86 VMs can trigger the EOI storm and controlled teardown without host root/CAP_SYS_ADMIN; only normal VM tenancy is needed, as guest halt causes the VMM to destroy the VM and run kvm_destroy_vm().
UI:NUser interaction, none
No action from another user or administrator is required; the attacker controls guest interrupt/EOI behavior and the timing of guest shutdown that prompts automatic VM destruction on typical hypervisors (QEMU/KVM, cloud instances).
S:CScope, changed
Use-after-free of host-kernel vCPU/LAPIC objects during IRQ delivery from pending IOAPIC delayed work crosses the KVM virtual-machine boundary and can enable guest-to-host kernel compromise on multi-tenant cloud and enterprise virtualization hosts.
C:HConfidentiality impact, high
KASAN confirmed a slab use-after-free reading freed vCPU/LAPIC pointers in __kvm_irq_delivery_to_apic_fast(); this UAF on host heap objects enables arbitrary kernel memory disclosure via controlled realloc/spray of the freed kvm_vcpu slab.
I:HIntegrity impact, high
The UAF dereferences freed vCPU state to inject APIC interrupts via kvm_apic_set_irq(), corrupting host kernel heap objects and providing write primitives exploitable for host code execution and VM escape.
A:HAvailability impact, high
Processing the delayed EOI work after vCPU destruction causes host kernel use-after-free during IRQ injection, reliably triggering KASAN-detected slab corruption and potential host kernel oops/panic on production KVM hypervisors.