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

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Unbounded user-controlled value for GICv5 `nr_spis` allows up to ~33.5 million SPIs, leading to massive `kcalloc`/`kzalloc` calls and triggering page allocator warnings (`WARN_ON_ONCE`).
--

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

KVM: arm64: gic-v5: Register the IRS IODEV

This patch registers the GICv5 IRS IODEV as part of vgic_map_resources. It
also allows userspace to configure the address of the emulated IRS and set
the number of SPIs handled by the GICv5 implementation.

> diff --git a/arch/arm64/kvm/vgic/vgic-kvm-device.c b/arch/arm64/kvm/vgic/vgic-kvm-device.c
> index 90be99443df3b..2bf1930902b8e 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,
[ ... ]
> +		} 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 > FIELD_MAX(GICV5_IRS_IDR5_SPI_RANGE) ||
> +			    (val & 31))
> +				return -EINVAL;

[Severity: High]
Does this allow an unprivileged userspace process to trigger massive
memory allocations and a kernel warning?

The validation here limits val to the 25-bit hardware maximum (around 33.5
million SPIs) rather than a smaller software-defined limit like
VGIC_MAX_RESERVED.

Later, when kvm_vgic_v5_irs_init() is called, it allocates the array:

	dist->spis = kcalloc(nr_spis, sizeof(struct vgic_irq),
			     GFP_KERNEL_ACCOUNT);

This could request over 4GB of physically contiguous memory. Similarly,
vgic_v5_alloc_linear_ist() does a kzalloc based on nr_spis, which could
request up to 256MB.

Since these allocations far exceed KMALLOC_MAX_SIZE and do not use
__GFP_NOWARN or kvcalloc(), would they unconditionally trigger a WARN_ON_ONCE
in the page allocator, allowing 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;
> +			mutex_unlock(&dev->kvm->arch.config_lock);
> +		}
>  
>  		return ret;
>  	}

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