Re: [PATCH v2] KVM: guest_memfd: Elaborate on how release() vs. get_pfn() is safe against UAF

[Sean Christopherson <seanjc@google.com>]

On Wed, Aug 26, 2026, sashiko-bot@kernel.org wrote:
> > diff --git a/virt/kvm/guest_memfd.c b/virt/kvm/guest_memfd.c
> > index b596486d184ca..7f1c6a0f8039d 100644
> > --- a/virt/kvm/guest_memfd.c
> > +++ b/virt/kvm/guest_memfd.c
> [ ... ]
> > @@ -300,17 +300,55 @@ static int kvm_gmem_release(struct inode *inode, struct file *file)
> >  	 * dereferencing the slot for existing bindings needs to be protected
> >  	 * against memslot updates, specifically so that unbind doesn't race
> >  	 * and free the memslot (kvm_gmem_get_file() will return NULL).
> >  	 */
> >  	mutex_lock(&kvm->slots_lock);
> >  
> >  	filemap_invalidate_lock(inode->i_mapping);
> >  
> > +	/*
> > +	 * Note!  synchronize_srcu() is _not_ needed after nullifying memslot
> [ ... ]
> > +	 * Obviously KVM would be broken in many places if the synchronization
> > +	 * were omitted, but it's important to note that get_file_active() does
> > +	 * NOT guarantee a reference to the correct file was obtained, only
> > +	 * that the file doesn't point at a reallocated object.
> > +	 */
> >  	xa_for_each(&f->bindings, index, slot)
> >  		WRITE_ONCE(slot->gmem.file, NULL);
> >  
> 
> [Severity: Critical]
> This is a pre-existing issue, but could bypassing filemap_invalidate_lock in
> kvm_gmem_unbind() when the file is dying allow concurrent xarray modifications
> that result in a use-after-free?

Yep, already reported by Sashiko and being fixed:
https://lore.kernel.org/all/20260823-shivank-gmem-fix-split-v1-1-512a29fb8e86@amd.com