CVE-2026-74517

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 _kvmirqdeliverytoapicfast+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 kvmioapiceoiinjectwork

  Call Trace:

   <TASK>

   _dumpstack lib/dump_stack.c:94

   dumpstacklvl+0x100/0x190 lib/dump_stack.c:120

   printaddressdescription mm/kasan/report.c:378

   print_report+0x139/0x4ad mm/kasan/report.c:482

   kasan_report+0xe4/0x1d0 mm/kasan/report.c:595

   _kvmirqdeliverytoapicfast+0x9bf/0xa20 arch/x86/kvm/lapic.c:1250

   _kvmirqdeliveryto_apic+0xd8/0xbf0 arch/x86/kvm/lapic.c:1345

   kvmirqdeliverytoapic arch/x86/kvm/lapic.h:129

   ioapic_service+0x308/0x590 arch/x86/kvm/ioapic.c:492

   kvmioapiceoiinjectwork+0x13c/0x190 arch/x86/kvm/ioapic.c:532

   processonework+0xa59/0x19a0 kernel/workqueue.c:3314

   processscheduledworks kernel/workqueue.c:3397

   worker_thread+0x5eb/0xe50 kernel/workqueue.c:3478

   kthread+0x370/0x450 kernel/kthread.c:436

   retfromfork+0x72b/0xd30 arch/x86/kernel/process.c:158

   retfromforkasm+0x1a/0x30 arch/x86/entry/entry64.S:245

   </TASK>

Note, the VM is unreachable once kvmdestroyvm() starts, and scheduling

new work via kvmioapicsendeoi() can only be done via KVMRUN, 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 ioapicinkernel() 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 kvmcpuhas_extint(), and it's not

hard to imagine the I/O APIC having a similar flaw.