Re: [PATCH v1] KVM: arm64: nv: Use kvm_phys_size() for VNCR invalidation range

[Marc Zyngier <maz@kernel.org>]

On Mon, 02 Feb 2026 14:54:55 +0000,
Fuad Tabba <tabba@google.com> wrote:
> 
> Hi Marc,
> 
> On Mon, 2 Feb 2026 at 14:45, Marc Zyngier <maz@kernel.org> wrote:
> >
> > On Mon, 02 Feb 2026 13:04:24 +0000,
> > Fuad Tabba <tabba@google.com> wrote:
> > >
> > > KVM: arm64: nv: Use kvm_phys_size() for VNCR invalidation range
> > >
> > > Protected mode uses `pkvm_mappings` of the union inside `struct kvm_pgtable`.
> > > This aliases `ia_bits`, which is used in non-protected mode.
> > >
> > > Attempting to use `pgt->ia_bits` in kvm_nested_s2_unmap() and
> > > kvm_nested_s2_wp() results in reading mapping pointers or state as a
> > > shift amount. This triggers a UBSAN shift-out-of-bounds error:
> > >
> > >     UBSAN: shift-out-of-bounds in arch/arm64/kvm/nested.c:1127:34
> > >     shift exponent 174565952 is too large for 64-bit type 'unsigned long'
> > >     Call trace:
> > >      __ubsan_handle_shift_out_of_bounds+0x28c/0x2c0
> > >      kvm_nested_s2_unmap+0x228/0x248
> > >      kvm_arch_flush_shadow_memslot+0x98/0xc0
> > >      kvm_set_memslot+0x248/0xce0
> > >
> > > Fix this by using kvm_phys_size() to determine the IPA size. This helper
> > > is independent of the software page table representation and works
> > > correctly for both protected and non-protected modes, as it derives the
> > > size directly from VTCR_EL2.
> >
> > I'm a bit confused by the explanation. We have plenty of code that
> > uses pgt->ia_bits outside of the NV code. And yet that code is not
> > affected by this?
> >
> > I'm asking because NV is clearly a case where the pkvm_mappings
> > aliasing is unambiguously *not* happening.
> >
> > Isn't the real issue that we are entering the NV handling code for any
> > S2 manipulation irrespective of NV support? Would something like below
> > help instead?
> 
> That would definitely work (just tested it). I just assumed that the
> code is there in case in the future we want to support nv + pkvm....
> Although, I chuckled a bit as I was writing those words :)

Don't laugh, I seriously considered what it would take to teach NV to
the RMM, just as a way to get rid of the ridiculous notion of planes
(which is exactly like NV, only done in a way that is even worse than
the architected version, so even more costly for no good reason).

> I was going to ask if you'd like me to respin, but this is a
> completely different patch. Would you like me to write it up and
> send it (my contribution would be the commit msg)?

Yes please, it's a lot less effort for me! :p

Thanks,

	M.

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