Re: [PATCH v3 1/2] KVM: x86: Don't WARN if IRQ disappears because it was cleared from the PIC

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] The patch resolves false-positive WARNs for missing interrupts by suppressing them when an in-kernel PIC is used, but fails to handle Xen event channels, leaving a guest-triggerable WARN for VMs without an in-kernel PIC.
--

--- Patch [1]: [PATCH v3 1/2] KVM: x86: Don't WARN if IRQ disappears because it was cleared from the PIC ---
commit 6c8d9104c0454cc3f831a546f5333b795c67a6aa
Author: Sean Christopherson <seanjc@google.com>

KVM: x86: Don't WARN if IRQ disappears because it was cleared from the PIC

This patch suppresses a warning when an IRQ disappears during injection for
VMs with an in-kernel PIC, as ExtINT handling tracks this per-VM. It keeps
the assert for split IRQCHIP VMs to help detect KVM bugs.

Closes: https://syzkaller.appspot.com/bug?extid=dd769db18693736eee89
Closes: https://lore.kernel.org/all/6a360fdf.871e809a.2d6dda.0000.GAE@google.com

> diff --git a/arch/x86/kvm/irq.h b/arch/x86/kvm/irq.h
> index 1a84ea31e7fd2..eeaf527cecc46 100644
> --- a/arch/x86/kvm/irq.h
> +++ b/arch/x86/kvm/irq.h
> @@ -118,6 +118,22 @@ int kvm_cpu_has_extint(struct kvm_vcpu *v);
>  int kvm_cpu_get_extint(struct kvm_vcpu *v);
>  int kvm_cpu_get_interrupt(struct kvm_vcpu *v);
>  
> +static inline void kvm_warn_on_lost_irq(struct kvm_vcpu *vcpu)
> +{
> +	/*
> +	 * WARN if an IRQ was lost between detecting the IRQ and grabbing the
> +	 * IRQ for injection, unless it's possible the lost IRQ was due to one
> +	 * of the exceptional cases below.
> +	 *
> +	 * If the VM has an in-kernel PIC, the ExtINT handling that's routed
> +	 * through KVM's virtual PIC is tracked per-VM, not per-vCPU.  If
> +	 * another vCPU grabs the IRQ, or deasserts the interrupt (which is
> +	 * level-triggered), then it's both expected and "fine" for an IRQ
> +	 * seemingly be "lost" from this vCPU's perspective.
> +	 */
> +	WARN_ON_ONCE(!pic_in_kernel(vcpu->kvm));

[Severity: High]
This is a pre-existing issue, but does this warning also need to account for
Xen event channels?

If a guest is configured with a split IRQCHIP and Xen emulation, can a
malicious guest concurrently toggle evtchn_upcall_pending in its shared
vcpu_info memory to intentionally trigger this warning?

The guest could create a race condition where kvm_cpu_has_injectable_intr()
returns true, but the guest clears the flag before kvm_cpu_get_interrupt()
is called. This would result in an irq of -1, triggering the warning here
because pic_in_kernel() evaluates to false for split IRQCHIPs.

Could this be used by an unprivileged guest to cause a host denial of
service if panic_on_warn is enabled?

> +}
> +
>  void kvm_inject_pending_timer_irqs(struct kvm_vcpu *vcpu);

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260724173425.278753-1-seanjc@google.com?part=1