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

[Yan Zhao]

On Tue, Jun 09, 2026 at 10:25:22AM -0700, Sean Christopherson wrote:
> 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 .
Ah, Ok.
 
> 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.
Ok. Thanks :)