Re: [PATCH v4 22/48] KVM: arm64: gic-v5: Register the IRS IODEV

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] GICv5 SPIs cannot be retrieved because vgic_get_irq() explicitly rejects non-private GICv5 IRQs, rendering the newly activated IRS SPI configuration broken.
- [High] Allowing userspace to configure up to 65,536 GICv5 SPIs triggers a large contiguous memory allocation via kcalloc, which can deterministically fail and cause kernel warnings, resulting in a host-side DoS.
--

--- Patch [22]: [PATCH v4 22/48] KVM: arm64: gic-v5: Register the IRS IODEV ---
commit d0f49503c9e90ab6ab9f71cb5ba22d59c564bcd8
Author: Sascha Bischoff <Sascha.Bischoff@arm.com>
KVM: arm64: gic-v5: Register the IRS IODEV

Now that we have an emulated IRS, it needs to be registered, which ensures that
guest accesses to the MMIO regions handled by the device are handled
appropriately in KVM. As part of this change, expose setting the address of
the emulated IRS via KVM_VGIC_V5_ADDR_TYPE_IRS to userspace. Also allow
userspace to set the number of SPIs handled by the emulated GICv5
implementation.

> diff --git a/arch/arm64/kvm/vgic/vgic-kvm-device.c b/arch/arm64/kvm/vgic/vgic-kvm-device.c
> index 90be99443df3b..8c2c6886af4e3 100644
> --- a/arch/arm64/kvm/vgic/vgic-kvm-device.c
> +++ b/arch/arm64/kvm/vgic/vgic-kvm-device.c

[ ... ]

> @@ -224,31 +232,48 @@ static int vgic_set_common_attr(struct kvm_device *dev,
>  		if (get_user(val, uaddr))
>  			return -EFAULT;
>  
> -		/*
> -		 * We require:
> -		 * - at least 32 SPIs on top of the 16 SGIs and 16 PPIs
> -		 * - at most 1024 interrupts
> -		 * - a multiple of 32 interrupts
> -		 */
> -		if (val < (VGIC_NR_PRIVATE_IRQS + 32) ||
> -		    val > VGIC_MAX_RESERVED ||
> -		    (val & 31))
> -			return -EINVAL;
> +		if (!vgic_is_v5(dev->kvm)) {

[ ... ]

> +		} else {
> +			/*
> +			 * GICv5 reports a number of SPIs, not a total number of
> +			 * interrupts. Require a multiple of 32 SPIs.
> +			 */
> +			if (val < VGIC_V5_DEFAULT_NR_SPIS ||
> +			    val > VGIC_V5_MAX_NR_SPIS ||
> +			    (val & 31))
> +				return -EINVAL;

[Severity: High]
Does allowing userspace to set nr_spis up to VGIC_V5_MAX_NR_SPIS (65536) risk
triggering a host-side allocation warning or failure?

If userspace sets nr_spis to the maximum, KVM will eventually call kcalloc()
for the SPIs:

arch/arm64/kvm/vgic/vgic-irs-v5.c:kvm_vgic_v5_irs_init() {
    ...
	dist->spis = kcalloc(nr_spis, sizeof(struct vgic_irq),
			     GFP_KERNEL_ACCOUNT);
    ...
}

Since sizeof(struct vgic_irq) is over 100 bytes, this requires a physically
contiguous allocation of roughly 7MB. This exceeds the typical KMALLOC_MAX_SIZE
of 4MB, which would cause the allocation to deterministically fail and
potentially trigger a kernel warning or panic (if panic_on_warn is set),
allowing an unprivileged user to cause a host-side denial of service.

> +
> +			mutex_lock(&dev->kvm->arch.config_lock);
> +			if (vgic_initialized(dev->kvm) || dev->kvm->arch.vgic.nr_spis)
> +				ret = -EBUSY;
> +			else
> +				dev->kvm->arch.vgic.nr_spis = val;

[Severity: High]
Are we able to retrieve these GICv5 SPIs once they are configured here?

Currently, vgic_get_irq() explicitly rejects non-private GICv5 IRQs:

arch/arm64/kvm/vgic/vgic.c:vgic_get_irq() {
    ...
	/* Non-private IRQs are not yet implemented for GICv5 */
	if (vgic_is_v5(kvm))
		return NULL;
    ...
}

This means that when the guest accesses the IRS MMIO interface for SPIs, the
handler (e.g., vgic_v5_mmio_write_irs_spi) will fail to retrieve the SPI
structure and silently abort. Will this leave GICv5 SPIs unconfigurable?

> +			mutex_unlock(&dev->kvm->arch.config_lock);
> +		}
>  
>  		return ret;
>  	}

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