Re: [PATCH v5 21/49] KVM: arm64: gic-v5: Initialise per-VM IRS state

[Sascha Bischoff <Sascha.Bischoff@arm.com>]

On Fri, 2026-08-07 at 14:49 +0000, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential
> issue(s) to consider:
> - [Medium] Unprivileged userspace can flood the kernel log (dmesg) by
> repeatedly triggering a `pr_warn` in `kvm_vgic_v5_irs_init()`.
> --
> 
> --- Patch [21]: [PATCH v5 21/49] KVM: arm64: gic-v5: Initialise per-
> VM IRS state ---
> commit 1471593eea3e98c7d1747cf0894424955cddde44
> Author: Sascha Bischoff <Sascha.Bischoff@arm.com>
> 
> KVM: arm64: gic-v5: Initialise per-VM IRS state
> 
> A virtual GICv5 needs an emulated IRS in addition to the host IRS
> state used to back VMTEs, VPEs, and ISTs. This patch allocates the
> per-VM emulated IRS state when creating a virtual GICv5, and
> initialises
> it from vgic_v5_init(). It also handles the teardown and cleanup of
> the
> IRS state during VGIC destruction.
> 
> > diff --git a/arch/arm64/kvm/vgic/vgic-v5.c
> > b/arch/arm64/kvm/vgic/vgic-v5.c
> > index 2932f3cfbe8f4..6a7dabf90dd1b 100644
> > --- a/arch/arm64/kvm/vgic/vgic-v5.c
> > +++ b/arch/arm64/kvm/vgic/vgic-v5.c
> 
> [ ... ]
> 
> > @@ -751,6 +752,11 @@ int vgic_v5_init(struct kvm *kvm)
> >  			goto err;
> >  	}
> >  
> > +	/* Init IRS (and alloc SPI IST) */
> > +	ret = kvm_vgic_v5_irs_init(kvm, kvm->arch.vgic.nr_spis);
> 
> [Severity: Medium]
> Does this new call path allow userspace to flood the kernel log?
> 
> When userspace initializes a GICv5 via ioctl, this path calls
> kvm_vgic_v5_irs_init(). If the host IRS hardware supports fewer than
> 16 ID
> bits for ISTs, kvm_vgic_v5_irs_init() emits an unconditional warning:
> 
> arch/arm64/kvm/vgic/vgic-irs-v5.c:kvm_vgic_v5_irs_init() {
>     ...
>     if (vgic_v5_irs_ist_id_bits(&irs_caps) < 16)
>         pr_warn("Host IRS supports fewer than 16 ID bits for ISTs
> (%u)\n",
>                 vgic_v5_irs_ist_id_bits(&irs_caps));
>     ...
> }
> 
> Since an unprivileged user can repeatedly create and destroy a VM in
> a tight
> loop, can this be used to spam dmesg and degrade system performance?
> Should
> this warning be converted to pr_warn_once() or be rate-limited?

I've made it rate-limited. I feel that us more useful than a
pr_warn_once().

> 
> > +	if (ret)
> > +		goto err;
> > +
> >  	return 0;
> >  
> >  err:
> 
Thanks,
Sascha