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

[Sean Christopherson <seanjc@google.com>]

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