Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "9.3",
  "pubDate": "2026-08-15T13:17:56.850Z",
  "pubdate": "2026-08-15T13:17:56.850Z",
  "executiveSummary": "A use-after-free vulnerability exists in the Linux kernel's KVM subsystem for x86 architectures, specifically within the I/O APIC delayed EOI (End of Interrupt) handling mechanism. The flaw arises due to an improper ordering of operations during virtual machine destruction, where delayed work items tied to I/O APIC EOI injection are canceled after the target vCPUs have already been destroyed.\nIf a scheduled work item executes after the vCPU structures are freed, it attempts to deliver an IRQ via __kvm_irq_delivery_to_apic_fast, referencing released memory and triggering a slab-use-after-free condition. This vulnerability impacts systems utilizing KVM virtualization on the Linux kernel.\nSuccessful exploitation of this flaw can lead to a denial of service (kernel panic or crash) and potentially arbitrary code execution or local privilege escalation depending on kernel heap layout and timing. Exploitation requires local access with permissions to interact with the KVM subsystem, specifically the ability to initiate and destroy virtual machines and trigger KVM_RUN operations to schedule work prior to VM teardown.",
  "technicalDetails": "The vulnerability resides in the Linux kernel KVM x86 virtualization implementation, specifically involving arch/x86/kvm/ioapic.c and arch/x86/kvm/lapic.c. The root cause is a race condition and lifecycle management flaw during virtual machine destruction in kvm_destroy_vm().\nDuring normal operation, the I/O APIC utilizes a delayed EOI handling mechanism implemented via workqueues (kvm_ioapic_eoi_inject_work). When an EOI is broadcasted, it may trigger the injection of another IRQ if the corresponding interrupt line remains asserted. This action requires delivering the IRQ to target vCPU structures.\nWhen a virtual machine is destroyed, KVM tears down vCPUs before completely cleaning up shared device state such as the I/O APIC. If the workqueue item kvm_ioapic_eoi_inject_work is scheduled but not canceled prior to vCPU destruction, a window opens where the delayed work processes after the vCPU memory has been freed back to the slab allocator.\nThe attack flow proceeds as follows: 1) An attacker with local access establishes a KVM-based virtual machine and interacts with devices to assert interrupt lines, scheduling delayed I/O APIC EOI injection work via kvm_ioapic_send_eoi(). 2) The attacker initiates the destruction of the VM. 3) KVM prematurely destroys the vCPU objects while the scheduled work item remains pending in the system workqueue (events). 4) The workqueue executes kvm_ioapic_eoi_inject_work, which calls ioapic_service(), kvm_irq_delivery_to_apic(), and subsequently __kvm_irq_delivery_to_apic_fast(). 5) The execution path attempts to read from and write to the freed vCPU/LAPIC memory structures located at ffff8880499abea0, triggering a KASAN slab-use-after-free report and crashing the kernel due to memory corruption.\nThe vulnerable component is the VM destruction sequence in the KVM x86 subsystem, specifically the lack of early cancellation and flushing of the I/O APIC delayed EOI work before vCPU deallocation. Authentication and privilege requirements match those needed to open /dev/kvm and manage virtual machines."
}