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

[Marc Zyngier]

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?

> 
> 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.

Thanks,

	M.

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