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

[Tao Cui <cui.tao@linux.dev>]

在 2026/8/28 17:36, Zeng Chi 写道:
> From: Zeng Chi <zengchi@kylinos.cn>
> 
> 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@vger.kernel.org
> Reported-by: Sashiko <sashiko-bot@kernel.org>
> Closes: https://lore.kernel.org/all/20260531140921.1B1181F00893@smtp.kernel.org/
> Signed-off-by: Zeng Chi <zengchi@kylinos.cn>
> ---
>  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@kylinos.cn>

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@smtp.kernel.org/