From: Paolo Bonzini <pbonzini@redhat.com>
To: Sean Christopherson <seanjc@google.com>
Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org,
zdi-disclosures@trendmicro.com,
Zhong Wang <wangzhong.c0ss4ck@bytedance.com>,
Xuanqing Shi <shixuanqing.11@bytedance.com>,
Weiming Shi <bestswngs@gmail.com>
Subject: Re: [PATCH v3] KVM: x86: Cancel delayed I/O APIC EOI handling before destroying vCPUs
Date: Tue, 28 Jul 2026 17:33:19 +0200 [thread overview]
Message-ID: <1800dfd2-5d55-4244-a69f-c7e16868b238@redhat.com> (raw)
In-Reply-To: <20260727171718.543491-1-seanjc@google.com>
On 7/27/26 19:17, Sean Christopherson wrote:
> From: Weiming Shi <bestswngs@gmail.com>
>
> 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.
>
> Fixes: 17bcd7144263 ("KVM: x86: Free vCPUs before freeing VM state")
> Reported-by: <zdi-disclosures@trendmicro.com>
> Reported-by: Zhong Wang <wangzhong.c0ss4ck@bytedance.com>
> Reported-by: Xuanqing Shi <shixuanqing.11@bytedance.com>
> Cc: stable@vger.kernel.org
> Signed-off-by: Weiming Shi <bestswngs@gmail.com>
> Co-developed-by: Sean Christopherson <seanjc@google.com>
> Signed-off-by: Sean Christopherson <seanjc@google.com>
Queued, thanks.
Paolo
> ---
>
> v3:
> - Go back to v1, sans the helper (x86.c already has an #ifdef). [Sean, syzbot]
> - Expand the block comment to call out the the PIC and I/O APIC must not be
> destroyed/free. [Kai]
>
> v2:
> - https://lore.kernel.org/all/20260706180025.2735341-3-bestswngs@gmail.com
> - Per Kai's suggestion, instead of adding a kvm_ioapic_pre_destroy()
> helper that only cancels the eoi_inject work, move
> kvm_pic_destroy()/kvm_ioapic_destroy() as a whole into
> kvm_arch_pre_destroy_vm(). This also fixes the stale
> kvm_io_bus_unregister_dev() Kai pointed out.
>
> v1: https://lore.kernel.org/all/20260705050443.1331662-1-bestswngs@gmail.com
>
> arch/x86/kvm/x86.c | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> index 0626e835e9eb..2b8474812303 100644
> --- a/arch/x86/kvm/x86.c
> +++ b/arch/x86/kvm/x86.c
> @@ -9939,9 +9939,15 @@ void kvm_arch_pre_destroy_vm(struct kvm *kvm)
> * iterating over vCPUs in a different task while vCPUs are being freed
> * is unsafe, i.e. will lead to use-after-free. The PIT also needs to
> * be stopped before IRQ routing is freed.
> + *
> + * Do NOT free the in-kernel PIC or I/O APIC here (but as above, make
> + * sure to flush any background work), as KVM expects interrupt routing
> + * structures to be valid until vCPUs are destroyed.
> */
> #ifdef CONFIG_KVM_IOAPIC
> kvm_free_pit(kvm);
> + if (kvm->arch.vioapic)
> + cancel_delayed_work_sync(&kvm->arch.vioapic->eoi_inject);
> #endif
>
> kvm_mmu_pre_destroy_vm(kvm);
>
> base-commit: a204badd8432f93b7e862e7dac6db0fe3d65f370
prev parent reply other threads:[~2026-07-28 15:33 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-27 17:17 [PATCH v3] KVM: x86: Cancel delayed I/O APIC EOI handling before destroying vCPUs Sean Christopherson
2026-07-28 0:18 ` Huang, Kai
2026-07-28 15:33 ` Paolo Bonzini [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1800dfd2-5d55-4244-a69f-c7e16868b238@redhat.com \
--to=pbonzini@redhat.com \
--cc=bestswngs@gmail.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=seanjc@google.com \
--cc=shixuanqing.11@bytedance.com \
--cc=wangzhong.c0ss4ck@bytedance.com \
--cc=zdi-disclosures@trendmicro.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox