[PATCH] KVM: arm64: Reallocate the nested_mmus array under the mmu_lock

[Marc Zyngier]

On Fri, 05 Jun 2026 06:35:20 +0100,
Hyunwoo Kim <imv4bel at gmail.com> wrote:
> 
> On Thu, Jun 04, 2026 at 03:27:16PM -0700, Oliver Upton wrote:
> > Hi,
> > 
> > The shortlog is very confusing, since "allocate behind $LOCK" is usually
> > something alarming. Maybe instead:
> > 
> >   KVM: arm64: Reassign nested_mmus array behind mmu_lock
> 
> heh, that's confusing indeed. I'll change it that way.
> 
> > 
> > On Fri, Jun 05, 2026 at 03:30:00AM +0900, Hyunwoo Kim wrote:
> > > Code that walks kvm->arch.nested_mmus[] holds kvm->mmu_lock. By contrast,
> > > kvm_vcpu_init_nested() reallocates the array and frees the old buffer while
> > > holding only kvm->arch.config_lock, so a walker can reference the freed
> > > array.
> > 
> > It wouldn't hurt to share slightly more information here. Are you
> > dealing with a concurrent MMU notifier?
> 
> Yes. The MMU notifier path also walks nested_mmus[] under mmu_lock.
> kvm_vcpu_init_nested() holds only config_lock, so if a notifier fires
> during vCPU init, it races with the array realloc and free.
> 
> Here's the reworked changelog. Should I send v2?
> 
>   kvm->arch.nested_mmus[] is walked under kvm->mmu_lock, including from the
>   MMU notifier path (kvm_unmap_gfn_range() -> kvm_nested_s2_unmap()), which
>   can run at any time. kvm_vcpu_init_nested() reallocates the array and frees
>   the old buffer while holding only kvm->arch.config_lock, so such a walker
>   can reference the freed array.
> 
>   Allocate the new array outside of mmu_lock, as the allocation can sleep.
>   Under the lock, copy the existing entries, fix up the back pointers and
>   reassign the array. Free the old buffer after dropping the lock, as
>   kvfree() can sleep as well.

That's significantly better. Please send a v2 with this.

Thanks,

	M.

-- 
Jazz isn't dead. It just smells funny.