Re: [PATCH v3 31/40] KVM: arm64: gic-v5: Add GICv5 SPI injection to irqfd

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Critical] The irqchip pin validation uses the dynamically configurable `nr_spis` without capping it to `KVM_IRQCHIP_NUM_PINS`, allowing userspace to trigger a heap buffer overflow in `setup_routing_entry()`.
--

commit d433fac30bf4700a907f87295b758ddff1f36b7c
Author: Sascha Bischoff <Sascha.Bischoff@arm.com>

KVM: arm64: gic-v5: Add GICv5 SPI injection to irqfd

This commit updates vgic_irqfd_set_irq() to translate irqchip pins into
GICv5 SPI IntIDs before injection. It also modifies the IRQCHIP route
validation to use the configured SPI count for GICv5.

> Also adjust IRQCHIP route validation for GICv5: use the configured SPI
> count, fall back to the default SPI count before VGIC init, and cap
> the accepted pin range to the generic irq routing table size.

The commit message states that the code caps the accepted pin range to the
generic irq routing table size, but it appears to use the configured SPI count
directly instead of capping it.

> diff --git a/arch/arm64/kvm/vgic/vgic-irqfd.c b/arch/arm64/kvm/vgic/vgic-irqfd.c
> --- a/arch/arm64/kvm/vgic/vgic-irqfd.c
> +++ b/arch/arm64/kvm/vgic/vgic-irqfd.c

[ ... ]

> @@ -45,15 +50,21 @@ int kvm_set_routing_entry(struct kvm *kvm,
>  			  struct kvm_kernel_irq_routing_entry *e,
>  			  const struct kvm_irq_routing_entry *ue)
>  {
> +	unsigned int nr_pins;
>  	int r = -EINVAL;
>  
> +	if (vgic_is_v5(kvm))
> +		nr_pins = kvm->arch.vgic.nr_spis;
> +	else
> +		nr_pins = KVM_IRQCHIP_NUM_PINS;
> +
>  	switch (ue->type) {
>  	case KVM_IRQ_ROUTING_IRQCHIP:
>  		e->set = vgic_irqfd_set_irq;
>  		e->irqchip.irqchip = ue->u.irqchip.irqchip;
>  		e->irqchip.pin = ue->u.irqchip.pin;
> -		if ((e->irqchip.pin >= KVM_IRQCHIP_NUM_PINS) ||
> -		    (e->irqchip.irqchip >= KVM_NR_IRQCHIPS))
> +		if (e->irqchip.pin >= nr_pins ||
> +		    e->irqchip.irqchip >= KVM_NR_IRQCHIPS)

[Severity: Critical]
Does this allow an out-of-bounds array write if userspace configures a
GICv5 VM with an nr_spis value larger than KVM_IRQCHIP_NUM_PINS?

If nr_pins can exceed KVM_IRQCHIP_NUM_PINS, the relaxed bounds check
here allows e->irqchip.pin to be larger than the size of the routing
table array.

The caller setup_routing_entry() uses this pin value to index directly
into the rt->chip array:

virt/kvm/irqchip.c:setup_routing_entry() {
    ...
    r = kvm_set_routing_entry(kvm, e, ue);
    if (r)
        goto out;
    ...
    rt->chip[e->irqchip.irqchip][e->irqchip.pin] = e->gsi;
    ...
}

Since KVM_IRQCHIP_NUM_PINS defines the size of the second dimension of
rt->chip, will a large e->irqchip.pin write the attacker-controlled e->gsi
value past the end of the array and corrupt the kernel heap?

>  			goto out;
>  		break;
>  	case KVM_IRQ_ROUTING_MSI:

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260703154811.3355680-1-sascha.bischoff@arm.com?part=31