From: sashiko-bot@kernel.org
To: "Shivank Garg" <shivankg@amd.com>
Cc: kvm@vger.kernel.org
Subject: Re: [PATCH v3 1/9] KVM: guest_memfd: take the invalidate lock when unbinding a dying file
Date: Wed, 05 Aug 2026 07:06:08 +0000 [thread overview]
Message-ID: <20260805070608.C447E1F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260805-shivank-gmem-migrate-v3-1-00d8bdec4e1d@amd.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [Critical] kvm_gmem_bind() ignores the return value of xa_store_range(), which can fail with -ENOMEM, leading to inconsistent memslot tracking and guest-to-host use-after-free.
--
--- Patch [1]: [PATCH v3 1/9] KVM: guest_memfd: take the invalidate lock when unbinding a dying file ---
commit 4192ee62a3c9cd53bedefe498647d781d59dfdf5
Author: Shivank Garg <shivankg@amd.com>
KVM: guest_memfd: take the invalidate lock when unbinding a dying file
This patch takes the invalidate lock during the dying-file path in
kvm_gmem_unbind() to prevent a race condition with memory failures.
It ensures the mmu_invalidate_in_progress counter remains balanced
when a binding is removed concurrently.
Link: https://lore.kernel.org/all/20260728092027.225CF1F000E9@smtp.kernel.org
> diff --git a/virt/kvm/guest_memfd.c b/virt/kvm/guest_memfd.c
> index db57c5766ab60..45cbdf4801ece 100644
> --- a/virt/kvm/guest_memfd.c
> +++ b/virt/kvm/guest_memfd.c
[ ... ]
[Severity: Critical]
This isn't a bug introduced by this patch, but there is a pre-existing
issue in kvm_gmem_bind() where an error return is ignored:
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;
err:
fput(file);
return r;
}
Does this code ignore the return value of xa_store_range(), which can fail
with -ENOMEM under memory pressure?
If xa_store_range() fails, the memslot won't be recorded in the guest_memfd
file's bindings. Subsequent host invalidations, such as FALLOC_FL_PUNCH_HOLE
or a memory failure, would fail to find the memslot and wouldn't invalidate
the guest's page tables.
Can this allow the guest to retain access to freed host memory, leading to
host memory use-after-free or cross-VM data corruption if the memory is
reallocated to other host processes?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260805-shivank-gmem-migrate-v3-0-00d8bdec4e1d@amd.com?part=1
next prev parent reply other threads:[~2026-08-05 7:06 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-05 6:40 [PATCH v3 0/9] KVM: guest_memfd: folio migration for non-confidential VMs Shivank Garg
2026-08-05 6:40 ` [PATCH v3 1/9] KVM: guest_memfd: take the invalidate lock when unbinding a dying file Shivank Garg
2026-08-05 7:06 ` sashiko-bot [this message]
2026-08-05 6:40 ` [PATCH v3 2/9] mm: split AS_UNMOVABLE back out of AS_INACCESSIBLE Shivank Garg
2026-08-05 6:40 ` [PATCH v3 3/9] KVM: guest_memfd: implement folio migration for non-confidential VMs Shivank Garg
2026-08-05 7:09 ` sashiko-bot
2026-08-05 6:40 ` [PATCH v3 4/9] KVM: guest_memfd: add GUEST_MEMFD_FLAG_MIGRATABLE Shivank Garg
2026-08-05 7:08 ` sashiko-bot
2026-08-05 6:40 ` [PATCH v3 5/9] KVM: selftests: fix maxnode arguments in xapic_ipi_test Shivank Garg
2026-08-05 6:40 ` [PATCH v3 6/9] KVM: selftests: use BITS_PER_TYPE() for NUMA masks Shivank Garg
2026-08-05 6:40 ` [PATCH v3 7/9] KVM: selftests: add get_numa_mem_nodes() Shivank Garg
2026-08-05 6:40 ` [PATCH v3 8/9] KVM: selftests: use allowed NUMA nodes in guest_memfd_test Shivank Garg
2026-08-05 6:40 ` [PATCH v3 9/9] KVM: selftests: exercise guest_memfd folio migration Shivank Garg
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260805070608.C447E1F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=kvm@vger.kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
--cc=shivankg@amd.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox