Re: [PATCH 1/5] KVM: guest_memfd: take the invalidate lock when unbinding a dying file

On Sun, Aug 23, 2026, [email protected] wrote:
> [Severity: High]
> This isn't a bug introduced by this patch, but does ignoring the return value
> of xa_store_range() here and in kvm_gmem_bind() lead to a use-after-free?
> 
> Looking at kvm_gmem_bind() in virt/kvm/guest_memfd.c, xa_store_range() is
> called with GFP_KERNEL:
> 
> virt/kvm/guest_memfd.c:kvm_gmem_bind() {
> 	...
> 	xa_store_range(&f->bindings, start, end - 1, slot, GFP_KERNEL);
> 	filemap_invalidate_unlock(inode->i_mapping);
> 
> 	/*
> 	 * Drop the reference to the file, even on success.  The file pins KVM,
> 	 * not the other way 'round.  Active bindings are invalidated if the
> 	 * file is closed before memslots are destroyed.
> 	 */
> 	r = 0;
> 	...
> }
> 
> If memory allocation fails during this operation, xa_store_range() returns an
> error pointer, but the return value is ignored. This masks ENOMEM errors and
> leads to an inconsistent state where the slot points to the file but the file
> doesn't track the slot.
> 
> Because the slot is missing from the file's XArray, when the file is later
> closed, kvm_gmem_release() iterates over f->bindings but fails to find this
> slot, leaving slot->gmem.file as a dangling pointer.
> 
> When the VM destroys the memslot, kvm_gmem_unbind() accesses this dangling
> pointer and calls get_file_active() on it. Can this cause a use-after-free on
> the freed struct file, or improperly increment the refcount of an unrelated,
> reused memory object?

Thanks Sashiko, for spilling the beans.  I've been sitting on a patch for about
a week (this got reported/found by multiple sources internally), I'll get it posted
today.