[PATCH] KVM: arm64: vgic-its: reject restored DTE with out-of-range num_eventid_bits

[Yao Yuan]

On Mon, May 18, 2026 at 09:23:08AM +0800, Marc Zyngier wrote:
> On Mon, 18 May 2026 07:05:13 +0100,
> Yao Yuan <yaoyuan at linux.alibaba.com> wrote:
> >
> > On Sun, May 17, 2026 at 01:49:55PM +0800, Michael Bommarito wrote:
>
> [...]
>
> > > diff --git a/arch/arm64/kvm/vgic/vgic-its.c b/arch/arm64/kvm/vgic/vgic-its.c
> > > index 2ea9f1c7ebcd0..a5dcf9a6a2854 100644
> > > --- a/arch/arm64/kvm/vgic/vgic-its.c
> > > +++ b/arch/arm64/kvm/vgic/vgic-its.c
> > > @@ -2307,6 +2307,15 @@ static int vgic_its_restore_dte(struct vgic_its *its, u32 id,
> > >  	/* dte entry is valid */
> > >  	offset = (entry & KVM_ITS_DTE_NEXT_MASK) >> KVM_ITS_DTE_NEXT_SHIFT;
> > >
> > > +	/*
> > > +	 * The MAPD command rejects this case; mirror the cap here so a
> > > +	 * restored DTE cannot install an out-of-range num_eventid_bits
> > > +	 * that vgic_its_restore_itt() would then convert into a
> > > +	 * sign-extended scan_its_table() length.
> > > +	 */
> > > +	if (num_eventid_bits > VITS_TYPER_IDBITS)
> > > +		return -EINVAL;
> >
> > Hi,
> >
> > IIUC, the same issue is still there when VITS_TYPER_IDBITS
> > change to >=28, I know it's limited to 16 in GITS_TYPER's
> > definition. I mean the issue is still there w/o really be
> > fixed.
>
> Change how? This is a hard-coded limit that reflect a practical use of
> the ITS (and is already 32 times larger than what PCIe allows).
>
> Are you suggesting a possibility of making this userspace
> configurable?

So far No, may until one day it has more than 16 definition :-)

>
> >
> > Change the scan_its_table() and other related code path to
> > avoid such date conversion issue is more reasonable
> > fixing to me, please also wait others' input yet.
>
> I don't think this is a reasonable course of action. scan_its_table()
> is generic (it doesn't know about any table in particular), and
> assumes that the scan parameters are validated upfront.

Ah I see.

I thought that even w/ chekcing VITS_TYPER_IDBITs, the
size_t -> int -> unsigned long conversion is still there, which is
big -> small -> big, looks odd to me, so I thought it should be fixed yet.
But it can't fix this issue directly.

>
> Thanks,
>
> 	M.
>
> --
> Without deviation from the norm, progress is not possible.