Re: [PATCH] LoongArch: KVM: Validate MSI data before routing it to EIOINTC

From: Tao Cui

Date: Mon Aug 31 2026 - 00:53:58 EST




在 2026/8/28 17:36, Zeng Chi 写道:
> From: Zeng Chi <zengchi@xxxxxxxxxx>
>
> pch_msi_set_irq() passes e->msi.data straight into eiointc_set_irq() as
> the irq number. The MSI data comes from userspace, either via a
> KVM_IRQ_ROUTING_MSI entry set with KVM_SET_GSI_ROUTING (used by irqfd
> and KVM_IRQ_LINE) or directly via KVM_SIGNAL_MSI, and is never checked
> against EIOINTC_IRQS.
>
> eiointc_set_irq() uses the value with __set_bit()/__clear_bit() on the
> 256-bit isr bitmap, eiointc_update_irq() then indexes sw_coremap[] and
> the per-cpu coreisr/sw_coreisr bitmaps with it. A data value >= 256
> therefore reads and writes memory past the end of those arrays, i.e.
> any process holding a VM fd can corrupt kernel memory beyond the
> loongarch_eiointc allocation.
>
> Reject MSI data that doesn't fit in the EIOINTC irq space. The DMSINTC
> path is unaffected as it decodes the vector from the address and masks
> it.
>
> Fixes: 1928254c5ccb ("LoongArch: KVM: Add irqfd support")
> Cc: stable@xxxxxxxxxxxxxxx
> Reported-by: Sashiko <sashiko-bot@xxxxxxxxxx>
> Closes: https://lore.kernel.org/all/20260531140921.1B1181F00893@xxxxxxxxxxxxxxx/
> Signed-off-by: Zeng Chi <zengchi@xxxxxxxxxx>
> ---
> arch/loongarch/kvm/intc/pch_pic.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/arch/loongarch/kvm/intc/pch_pic.c b/arch/loongarch/kvm/intc/pch_pic.c
> index e7b77705c516..81fb534ce8dd 100644
> --- a/arch/loongarch/kvm/intc/pch_pic.c
> +++ b/arch/loongarch/kvm/intc/pch_pic.c
> @@ -78,6 +78,9 @@ int pch_msi_set_irq(struct kvm *kvm, struct kvm_kernel_irq_routing_entry *e, int
> return dmsintc_set_irq(kvm, msg_addr, e->msi.data, level);
> }
>
> + if (e->msi.data >= EIOINTC_IRQS)
> + return -EINVAL;
> +
> eiointc_set_irq(kvm->arch.eiointc, e->msi.data, level);
>
> return 0;
Nice fix, thanks!

Reviewed-by: Tao Cui <cuitao@xxxxxxxxxx>

BTW, the NULL deref in pch_pic_update_irq() that Sashiko mentioned is
a pre-existing issue — it might be worth addressing in a separate
patch:
https://lore.kernel.org/all/20260828100204.CC38D1F000E9@xxxxxxxxxxxxxxx/