From: sashiko-bot@kernel.org
To: syzbot <syzbot@kernel.org>
Cc: kvm@vger.kernel.org
Subject: Re: [PATCH v2] KVM: x86: Exempt in-kernel PIC from "disappearing" interrupt warning
Date: Thu, 25 Jun 2026 21:20:00 +0000 [thread overview]
Message-ID: <20260625212001.3B6561F000E9@smtp.kernel.org> (raw)
In-Reply-To: <86078441-92eb-4461-b823-7d3539ac5859@mail.kernel.org>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
New issues:
- [Medium] The `!pic_in_kernel(vcpu->kvm)` check inadvertently suppresses the warning for APIC bugs in the default full-irqchip mode, contradicting the commit's intent.
Pre-existing issues:
- [High] A malicious guest can still trigger the `WARN_ON_ONCE` in `kvm_check_and_inject_events` when KVM is configured with a split irqchip and Xen emulation is enabled.
--
commit a01ce83aaf4bff44e757aa3ac163f97e316b3056
Author: Alexander Potapenko <glider@google.com>
KVM: x86: Exempt in-kernel PIC from "disappearing" interrupt warning
This commit addresses a time-of-check to time-of-use race condition in the
in-kernel PIC that triggers a kernel warning when an interrupt disappears
between check and fetch. It modifies kvm_check_and_inject_events() to exempt
the in-kernel PIC from this warning. The intent is to preserve the warning
for other interrupt sources like the APIC.
Link: https://syzkaller.appspot.com/ai_job?id=0b59ccd5-8820-460d-84d3-94df6307bd6a
> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> --- a/arch/x86/kvm/x86.c
> +++ b/arch/x86/kvm/x86.c
[ ... ]
> @@ -10857,7 +10857,9 @@ static int kvm_check_and_inject_events(struct kvm_vcpu *vcpu,
> if (r) {
> int irq = kvm_cpu_get_interrupt(vcpu);
>
> - if (!WARN_ON_ONCE(irq == -1)) {
> + WARN_ON_ONCE(irq == -1 && !pic_in_kernel(vcpu->kvm));
[Severity: Medium]
Does this inadvertently suppress the warning for APIC bugs in the default
full-irqchip mode?
Since pic_in_kernel() evaluates to true when the in-kernel PIC is present,
checking !pic_in_kernel() disables the warning entirely for all interrupt
sources in that configuration. This appears to contradict the commit message
intent of preserving the warning for other sources like the APIC.
[Severity: High]
This is a pre-existing issue, but can a malicious guest still trigger this
warning when KVM is configured with a split irqchip and Xen emulation is
enabled?
If a guest concurrently toggles its evtchn_upcall_pending flag in memory
while the host executes the event injection loop, it seems this path is
directly reachable. Because pic_in_kernel() is false for a split irqchip,
the warning could still fire and potentially lead to a host panic if
panic_on_warn is enabled.
> +
> + if (irq != -1) {
> kvm_queue_interrupt(vcpu, irq, false);
> kvm_x86_call(inject_irq)(vcpu, false);
> WARN_ON(kvm_x86_call(interrupt_allowed)(vcpu, true) < 0);
--
Sashiko AI review · https://sashiko.dev/#/patchset/86078441-92eb-4461-b823-7d3539ac5859@mail.kernel.org?part=1
next prev parent reply other threads:[~2026-06-25 21:20 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-25 21:10 [PATCH v2] KVM: x86: Exempt in-kernel PIC from "disappearing" interrupt warning syzbot
2026-06-25 21:20 ` sashiko-bot [this message]
2026-06-25 22:34 ` Aleksandr Nogikh
2026-06-25 22:38 ` Sean Christopherson
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=20260625212001.3B6561F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=kvm@vger.kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
--cc=syzbot@kernel.org \
/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