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

[Sean Christopherson <seanjc@google.com>]

On Tue, Jun 09, 2026, Yan Zhao wrote:
> On Mon, Jun 08, 2026 at 06:41:23PM -0700, Sean Christopherson wrote:
> > On Fri, Jun 05, 2026, Yan Zhao wrote:
> > In kvm_gmem_get_pfn(), because slots_lock isn't held, this could happen if
> > kvm_set_memory_region() didn't synchronize_srcu().
> >  
> >   CPU0                                    CPU1
> >   kvm_gmem_get_pfn()                     
> >     f = X (from slot->gmem.file)
> > 
> >                                           kvm_gmem_release())
> >                                             slot->gmem.file = NULL
> > 
> >
> >                                           kvm_set_memory_region()
> >                                             slot deleted
> >
> >                                           kvm_set_memory_region()
> >                                             slot created
> >                                             slot->gmem.file = f (alloc the same object)
> > 
> >   get_file_active()
> >     file = f
> >     file_reloaded = f
> >   <KVM does weird things with an old memslot+file> 
> > 
> > Obviously KVM would be wildly broken for other reasons, but just saying
> > get_file_active() takes care of everything is misleading because it only handles
> > reallocation of the object, it doesn't guarantee a reference to the correct file
> > was obtained.
> Ok. Thanks for the explanation. I get your point now.
> 
> My previous confusion came from the fact that if kvm_set_memory_region() does
> not wait for all users of the slot being deleted to exit the SRCU read critical
> section before committing the slot deletion, KVM would be wildly broken
> regardless of whether gmem is released.
> 
> > E.g. AFAICT, users of get_mm_exe_file() don't care if they race with
> > replace_mm_exe_file(), they only care that they have a reference to a live file.
> > 
> > KVM on the other hand cares that kvm_gmem_get_pfn() gets the exact file that is
> > associated with its memslot point.
> If slot->gmem.file can be set back to a non-null value without the memslot first
> being deleted, synchronize_srcu() in release() isn't required, right?
> 
>   CPU0                                    CPU1
>   kvm_gmem_get_pfn()                     
>     f = X (from slot->gmem.file)
> 
>                                           kvm_gmem_release())
>                                             slot->gmem.file = NULL
> 
>                                            kvm_set_memory_region()
>                                              slot->gmem.file = f (alloc the same object)
>  
>    get_file_active()
>      file = f
>      file_reloaded = f
> 
>    <KVM proceeds here should be fine with slot + new file> 

Not really?  There are no guarantees that the old slot and new slot have the same
GPA range and the same gfn=>gmem bindings.  E.g. __kvm_gmem_get_pfn() could get
invoked with an out-of-range index, or worse could provide the wrong pfn due to
computing .

It's kind of an impossible question to answer though, because it's sooo far down
a hypothetical path where a KVM bug basically means all bets are off.