Re: [PATCH 3/3] KVM: guest_memfd: Handle errors from xa_store_range() when binding

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Critical] Propagating `xa_store_range()` failure causes a Use-After-Free due to a missing rollback of partially stored XArray entries.
--

commit cacb3f43fb3479e4984fbb068881df5efe05c882
Author: Ackerley Tng <ackerleytng@google.com>

KVM: guest_memfd: Handle errors from xa_store_range() when binding

This commit updates kvm_gmem_bind() to check the return value of
xa_store_range() and propagate any resulting errors back to userspace,
rather than falsely reporting success.

> diff --git a/virt/kvm/guest_memfd.c b/virt/kvm/guest_memfd.c
> index d203135969d13..104f0f3d6a0b3 100644
> --- a/virt/kvm/guest_memfd.c
> +++ b/virt/kvm/guest_memfd.c
[ ... ]
> @@ -688,7 +689,7 @@ int kvm_gmem_bind(struct kvm *kvm, struct kvm_memory_slot *slot,
>  	if (kvm_gmem_supports_mmap(inode))
>  		slot->flags |= KVM_MEMSLOT_GMEM_ONLY;
>  
> -	xa_store_range(&f->bindings, start, end - 1, slot, GFP_KERNEL);
> +	result = xa_store_range(&f->bindings, start, end - 1, slot, GFP_KERNEL);
>  	filemap_invalidate_unlock(inode->i_mapping);
>  
>  	/*
> @@ -696,7 +697,7 @@ int kvm_gmem_bind(struct kvm *kvm, struct kvm_memory_slot *slot,
>  	 * not the other way 'round.  Active bindings are invalidated if the
>  	 * file is closed before memslots are destroyed.
>  	 */
> -	r = 0;
> +	r = xa_is_err(result) ? xa_err(result) : 0;

[Severity: Critical]
If xa_store_range() fails midway through storing a large range (for example,
returning -ENOMEM), does it leave the already-processed entries in the
f->bindings XArray?

When this error is propagated back, the caller __kvm_set_memory_region()
will abort the operation and free the memslot without calling
kvm_gmem_unbind().

Since the partial XArray updates aren't rolled back here, could this leave
dangling pointers to the freed memslot in f->bindings? If so, when the file
is eventually closed, kvm_gmem_release() might iterate over these dangling
pointers and write to slot->gmem.file, resulting in a use-after-free.

>  err:
>  	fput(file);
>  	return r;

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260522-fix-sev-gmem-post-populate-v1-0-9fc8d6437b65@google.com?part=3