UBUNTU-CVE-2026-74517: Use After Free

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/dumpstack.c:94 dumpstacklvl+0x100/0x190 lib/dumpstack.c:120 printaddressdescription mm/kasan/report.c:378 printreport+0x139/0x4ad mm/kasan/report.c:482 kasanreport+0xe4/0x1d0 mm/kasan/report.c:595 kvmirqdeliverytoapicfast+0x9bf/0xa20 arch/x86/kvm/lapic.c:1250 kvmirqdeliverytoapic+0xd8/0xbf0 arch/x86/kvm/lapic.c:1345 kvmirqdeliverytoapic arch/x86/kvm/lapic.h:129 ioapicservice+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 workerthread+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 kvmcpuhasextint(), and it's not hard to imagine the I/O APIC having a similar flaw.