Re: [PATCH v2] KVM: x86: Exempt in-kernel PIC from "disappearing" interrupt warning
Aleksandr Nogikh <[email protected]>
| Newsgroups | dev.linux.lists.syzbot,org.kernel.vger.kvm,org.kernel.vger.linux-kernel |
|---|---|
| Message-ID | <CANp29Y7aiAeNCUPAYbym7_b7gxDsjweF+qssQ-VSussbZ1OGgw@mail.gmail.com> |
On Thu, Jun 25, 2026 at 11:10 PM 'syzbot' via syzkaller-bugs <[email protected]> wrote: > > From: Alexander Potapenko <[email protected]> > > 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 in the > in-kernel PIC 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. > > 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 for the in-kernel PIC, WARN_ON_ONCE() must not be used for this > case. Update the warning to exempt the in-kernel PIC, while preserving it > for other interrupt sources (e.g. APIC) as they are not expected to exhibit > this behavior. > > 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: [email protected] > Closes: https://syzkaller.appspot.com/bug?extid=dd769db18693736eee89 > Link: https://syzkaller.appspot.com/ai_job?id=0b59ccd5-8820-460d-84d3-94df6307bd6a > Signed-off-by: Alexander Potapenko <[email protected]> > > --- > v2: > - Restrict the warning exemption to the in-kernel PIC case. > - Remove the pr_err_ratelimited() logging. > - Preserve the WARN_ON_ONCE() for non-PIC interrupt sources. > > v1: > https://lore.kernel.org/all/[email protected]/T/ > --- > diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c > index 0550359ed..f1681aa9f 100644 > --- 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)); > + > + if (irq != -1) { Hmm, no, that looks weird. Sorry for the noise, please ignore. > kvm_queue_interrupt(vcpu, irq, false); > kvm_x86_call(inject_irq)(vcpu, false); > WARN_ON(kvm_x86_call(interrupt_allowed)(vcpu, true) < 0); > > > 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 [email protected]. >