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

[Yan Zhao <yan.y.zhao@intel.com>]

On Mon, Sep 21, 2026 at 06:43:52AM -0700, Sean Christopherson wrote:
> On Mon, Sep 21, 2026, Sean Christopherson wrote:
> > On Sun, Sep 20, 2026, Yan Zhao wrote:
> > > On Wed, Aug 26, 2026 at 09:56:47AM -0700, Sean Christopherson wrote:
> > > Do we need to update the code comment in __kvm_gmem_unbind() from
> > > 	/*
> > > 	 * synchronize_srcu(&kvm->srcu) ensured that kvm_gmem_get_pfn()
> > > 	 * cannot see this memslot.
> > > 	 */
> > > to
> > > 	/*
> > > 	 * synchronize_srcu_expedited() in kvm_swap_active_memslots() ensured
> > > 	 * that kvm_gmem_get_pfn() cannot see this memslot.
> > > 	 */
> > > 
> > > to align with the above comment.
> > 
> > How about this?  Because the "rule" is that kvm_gmem_unbind() can only be called
> > on a memslot that is unreachable, either by synchronizing SRCU after uninstalling
> > the memslot *or* because the memslot was never installed.  Simply stating that
> > synchronize_srcu_expedited() makes everything safe isn't the whole story, as it's
> > specifically synchronzing after removing/deleting/deactivating the slot that
> > makes this safe.
> > 
> > 	/*
> > 	 * Note, the caller is responsible for ensuring the slot is unreachable
> > 	 * before unbinding, e.g. by synchronizing SRCU after deleting the slot.
> > 	 */
> 
> Hmm, though it's probably a good idea to preserve the connection to kvm_gmem_get_pfn():
> 
> 	/*
> 	 * Note, the caller is responsible for ensuring the slot is unreachable
> 	 * before unbinding, e.g. by synchronizing SRCU after deleting the slot,
> 	 * to guarantee kvm_gmem_get_pfn() can't see the slot+file.
> 	 */
LGTM.