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

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

[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;
-- 
2.25.1


No virus found
		Checked by Hillstone Network AntiVirus

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

[sashiko-bot]

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

Pre-existing issues:
- [Critical] Preexisting NULL pointer dereference in pch_pic_update_irq() when EIOINTC is not instantiated.
--

commit 2e412c04f647995bc67015a157c68cab104e2514
Author: Zeng Chi <zengchi@kylinos.cn>

    LoongArch: KVM: Validate MSI data before routing it to EIOINTC
    
    pch_msi_set_irq() passes e->msi.data straight into eiointc_set_irq() as
    the irq number. The MSI data comes from userspace and is never checked
    against EIOINTC_IRQS, which can corrupt kernel memory. This patch
    rejects MSI data that doesn't fit in the EIOINTC irq space.

> diff --git a/arch/loongarch/kvm/intc/pch_pic.c b/arch/loongarch/kvm/intc/pch_pic.c
> index e7b77705c516a..81fb534ce8dd5 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);

[Severity: Critical]
This isn't a bug introduced by this patch, but is it possible for
s->kvm->arch.eiointc to be unconditionally dereferenced as a NULL pointer
in pch_pic_update_irq() when the EIOINTC device is not instantiated?

A KVM userspace process can create a KVM_DEV_TYPE_LOONGARCH_PCHPIC device
via ioctl without creating the KVM_DEV_TYPE_LOONGARCH_EIOINTC device.

If the process pre-populates the irr (Interrupt Request Register) of the
PCHPIC device using the KVM_SET_DEVICE_ATTR ioctl, and then runs a guest
VCPU to perform an MMIO write to PCH_PIC_MASK_START to unmask the pending
interrupt, it bypasses standard KVM IRQ injection checks.

This results in the following path:

loongarch_pch_pic_write() -> pch_pic_update_batch_irqs() -> pch_pic_update_irq()

arch/loongarch/kvm/intc/pch_pic.c:pch_pic_update_irq() {
	...
	if (level) {
		if (mask & s->irr & ~s->mask) {
			s->isr |= mask;
			irq = s->htmsi_vector[irq];
			eiointc_set_irq(s->kvm->arch.eiointc, irq, level);
	...
}

Because EIOINTC was never created, the pointer is NULL. Because
eiointc_set_irq() unconditionally dereferences it via s->isr, can this
malicious guest action trigger an immediate host kernel panic?

>  
>  	return 0;
>  }

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260828093604.56622-1-zeng_chi911@163.com?part=1