* Re: [PATCH] KVM: x86: Drop WARN_ON_ONCE() for concurrently disappearing interrupts
2026-06-24 13:15 [PATCH] KVM: x86: Drop WARN_ON_ONCE() for concurrently disappearing interrupts syzbot
@ 2026-06-24 13:23 ` sashiko-bot
2026-06-24 14:00 ` Sean Christopherson
1 sibling, 0 replies; 3+ messages in thread
From: sashiko-bot @ 2026-06-24 13:23 UTC (permalink / raw)
To: syzbot; +Cc: kvm
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Guest-triggerable host log spam via pr_err_ratelimited() for a normal TOCTOU condition.
--
commit 116bec97d294fdbb66935efe3243c46e486faba6
Author: Alexander Potapenko <glider@google.com>
KVM: x86: Drop WARN_ON_ONCE() for concurrently disappearing interrupts
This commit removes a warning in kvm_check_and_inject_events() that occurs
when an interrupt disappears between being checked and fetched. Since this
is a legitimate race condition, the warning is replaced with a rate-limited
error message.
Link: https://syzkaller.appspot.com/ai_job?id=35cad3cd-95fd-4c0d-8ca8-812f58d56e59
> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> index 0550359ed798f..c5b4cddd9c0cb 100644
> --- a/arch/x86/kvm/x86.c
> +++ b/arch/x86/kvm/x86.c
> @@ -10857,10 +10857,13 @@ 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)) {
> + 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);
> + } else {
> + pr_err_ratelimited(
> + "KVM: interrupt disappeared between checking and fetching\n");
[Severity: Medium]
Since the commit message identifies this as a legitimate race condition that
can occur during normal operation, could this pr_err_ratelimited() allow an
unprivileged guest to continuously spam the host kernel log?
By configuring a PIT or PCI device to rapidly assert and deassert
level-triggered interrupts, a guest could intentionally trigger this path and
force the host to log messages at the maximum rate-limited frequency
indefinitely.
Should this event be logged with pr_warn_once() instead, or dropped entirely
to prevent adversary-reachable host log pollution?
> + }
> }
> if (kvm_cpu_has_injectable_intr(vcpu))
--
Sashiko AI review · https://sashiko.dev/#/patchset/345e9d6c-d7d9-4bab-adb3-d6a7bd27599f@mail.kernel.org?part=1
^ permalink raw reply [flat|nested] 3+ messages in thread* Re: [PATCH] KVM: x86: Drop WARN_ON_ONCE() for concurrently disappearing interrupts
2026-06-24 13:15 [PATCH] KVM: x86: Drop WARN_ON_ONCE() for concurrently disappearing interrupts syzbot
2026-06-24 13:23 ` sashiko-bot
@ 2026-06-24 14:00 ` Sean Christopherson
1 sibling, 0 replies; 3+ messages in thread
From: Sean Christopherson @ 2026-06-24 14:00 UTC (permalink / raw)
To: syzbot
Cc: syzkaller-bugs, Borislav Petkov, Dave Hansen, kvm, Ingo Molnar,
Paolo Bonzini, Thomas Gleixner, x86, hpa, linux-kernel, syzbot
On Wed, Jun 24, 2026, syzbot wrote:
> From: Alexander Potapenko <glider@google.com>
>
> A warning can be triggered in kvm_check_and_inject_events() when an
> interrupt disappears between the time it is checked via
> kvm_cpu_has_injectable_intr() and the time it is fetched via
> kvm_cpu_get_interrupt(). This occurs because the warning incorrectly
> assumes that if an interrupt is injectable, fetching it must always return
> a valid interrupt vector (i.e., not -1).
>
> However, this assumption is broken by level-triggered interrupts that are
> deasserted concurrently by another thread. For example, if a misconfigured
> PIT or a PCI device asserts and then immediately deasserts a
> level-triggered interrupt, the VCPU thread might see the pending interrupt
> during the check but find it gone during the fetch, resulting in
> kvm_cpu_get_interrupt() returning -1.
I think this the race is limited to the PIC case, no? Because for all other
cases, mucking with pending IRQs requires holding vcpu->mutex.
So rather than removing the WARN entirely, can't we fix this by exempting the
in-kernel PIC case? Given that we're pushing hard to move to a split IRQCHIP
model, this would preserve the WARN for the use case we care most about.
diff --git arch/x86/kvm/x86.c arch/x86/kvm/x86.c
index 3a2e4493516f..64f6592f5b23 100644
--- arch/x86/kvm/x86.c
+++ arch/x86/kvm/x86.c
@@ -7694,7 +7694,7 @@ 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)) {
+ if (!WARN_ON_ONCE(irq == -1 && !pic_in_kernel(vcpu->kvm))) {
kvm_queue_interrupt(vcpu, irq, false);
kvm_x86_call(inject_irq)(vcpu, false);
WARN_ON(kvm_x86_call(interrupt_allowed)(vcpu, true) < 0);
> The warning manifests as follows:
>
> ------------[ cut here ]------------
> irq == -1
> WARNING: arch/x86/kvm/x86.c:10860 at kvm_check_and_inject_events
> arch/x86/kvm/x86.c:10860 [inline]
> WARNING: arch/x86/kvm/x86.c:10860 at vcpu_enter_guest
> arch/x86/kvm/x86.c:11356 [inline]
> WARNING: arch/x86/kvm/x86.c:10860 at vcpu_run+0x57ec/0x7950
> arch/x86/kvm/x86.c:11770
> RIP: 0010:kvm_check_and_inject_events arch/x86/kvm/x86.c:10860 [inline]
> RIP: 0010:vcpu_enter_guest arch/x86/kvm/x86.c:11356 [inline]
> RIP: 0010:vcpu_run+0x57ec/0x7950 arch/x86/kvm/x86.c:11770
> Call Trace:
> <TASK>
> kvm_arch_vcpu_ioctl_run+0x1193/0x2070 arch/x86/kvm/x86.c:12125
> kvm_vcpu_ioctl+0xa61/0xfd0 virt/kvm/kvm_main.c:4470
> vfs_ioctl fs/ioctl.c:51 [inline]
> __do_sys_ioctl fs/ioctl.c:597 [inline]
> __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:583
> do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
> do_syscall_64+0x174/0x580 arch/x86/entry/syscall_64.c:94
> entry_SYSCALL_64_after_hwframe+0x77/0x7f
> </TASK>
>
> Since this is a legitimate Time-Of-Check to Time-Of-Use (TOCTOU) race
> condition that can occur during normal operation, WARN_ON_ONCE() must not
> be used for conditions that can legitimately happen. The patch removes the
> WARN_ON_ONCE() in kvm_check_and_inject_events() and replaces it with a
> pr_err_ratelimited() to log the event instead.
If we can't salvage the WARN, I don't want to log anything to dmesg. The purpose
of the WARN is to find KVM bugs. A ratelimited printk isn't going to help on that
front.
> Fixes: bf672720e83c ("KVM: x86: check the kvm_cpu_get_interrupt result before using it")
> Assisted-by: Gemini:gemini-3.1-pro-preview Gemini:gemini-3-flash-preview syzbot
> Reported-by: syzbot+dd769db18693736eee89@syzkaller.appspotmail.com
> Closes: https://syzkaller.appspot.com/bug?extid=dd769db18693736eee89
> Link: https://syzkaller.appspot.com/ai_job?id=35cad3cd-95fd-4c0d-8ca8-812f58d56e59
> Signed-off-by: Alexander Potapenko <glider@google.com>
>
> ---
> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> index 0550359ed..c5b4cddd9 100644
> --- a/arch/x86/kvm/x86.c
> +++ b/arch/x86/kvm/x86.c
> @@ -10857,10 +10857,13 @@ 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)) {
> + 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);
> + } else {
> + pr_err_ratelimited(
> + "KVM: interrupt disappeared between checking and fetching\n");
> }
> }
> if (kvm_cpu_has_injectable_intr(vcpu))
>
>
> base-commit: 8cd9520d35a6c38db6567e97dd93b1f11f185dc6
> --
> See https://goo.gle/syzbot-ai-patches for information about AI-generated patches.
> You can comment on the patch as usual, syzbot will try to address
> the comments and send a new version of the patch if necessary.
> syzbot engineers can be reached at syzkaller@googlegroups.com.
^ permalink raw reply related [flat|nested] 3+ messages in thread