From: sashiko-bot@kernel.org
To: "Jörg Rödel" <joro@8bytes.org>
Cc: kvm@vger.kernel.org
Subject: Re: [PATCH 3/4] KVM: guest_memfd: Add `write` parameter to kvm_gmem_populate()
Date: Tue, 23 Jun 2026 09:32:31 +0000 [thread overview]
Message-ID: <20260623093231.B4CA91F00A3A@smtp.kernel.org> (raw)
In-Reply-To: <20260623091556.1500930-4-joro@8bytes.org>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
New issues:
- [Low] The integer `write` parameter is passed directly as the `gup_flags` bitmask to `get_user_pages_fast()`, treating a bitmask as a boolean.
Pre-existing issues:
- [Medium] Modified user pages acquired via `get_user_pages_fast()` are not marked dirty before their reference is dropped, leading to potential data loss.
--
commit 49441863078cd5114f78eb8c75f1d31489417864
Author: Joerg Roedel <joerg.roedel@amd.com>
KVM: guest_memfd: Add write parameter to kvm_gmem_populate()
This commit adds a write parameter to kvm_gmem_populate() to optionally
acquire a writable reference to the user-space page via get_user_pages_fast().
This ensures page permissions are enforced when KVM needs to write error
details back to userspace.
> diff --git a/virt/kvm/guest_memfd.c b/virt/kvm/guest_memfd.c
> index 69c9d6d546b28..7a245a402a1b2 100644
> --- a/virt/kvm/guest_memfd.c
> +++ b/virt/kvm/guest_memfd.c
[ ... ]
> @@ -893,7 +893,7 @@ long kvm_gmem_populate(struct kvm *kvm, gfn_t start_gfn, void __user *src, long
> if (src) {
> unsigned long uaddr = (unsigned long)src + i * PAGE_SIZE;
>
> - ret = get_user_pages_fast(uaddr, 1, 0, &src_page);
> + ret = get_user_pages_fast(uaddr, 1, write, &src_page);
[Severity: Low]
Does this pass an integer parameter directly into the gup_flags argument?
While the integer value 1 coincidentally evaluates to FOLL_WRITE (1 << 0),
is it safe to rely on the numeric value of an internal macro definition here?
Would it be more robust to explicitly pass FOLL_WRITE based on the write
parameter?
[Severity: Medium]
This is a pre-existing issue, but since we are explicitly handling writable
pages here, are we missing a dirty page notification before the reference
is dropped?
If a user-provided CPUID page fails validation during a SEV-SNP VM launch,
sev_gmem_post_populate() modifies the page directly via memcpy() bypassing
the user page tables. However, kvm_gmem_populate() drops the reference
shortly after:
virt/kvm/guest_memfd.c:kvm_gmem_populate() {
...
ret = __kvm_gmem_populate(...);
if (src_page)
put_page(src_page);
...
}
Does this drop the reference without calling set_page_dirty_lock() or an
equivalent dirtying function? If so, could the memory management subsystem
reclaim the unmarked page and cause userspace to read stale data instead of
the detailed error information?
> if (ret < 0)
> break;
> if (ret != 1) {
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260623091556.1500930-1-joro@8bytes.org?part=3
next prev parent reply other threads:[~2026-06-23 9:32 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-23 9:15 [PATCH 0/4] kvm: sev: Fix issues reported by Sashiko Jörg Rödel
2026-06-23 9:15 ` [PATCH 1/4] kvm: sev: Fix user-space triggerable WARN_ON on snp_launch_update path Jörg Rödel
2026-06-23 9:32 ` sashiko-bot
2026-06-23 14:46 ` Sean Christopherson
2026-06-23 9:15 ` [PATCH 2/4] kvm: sev: Unmap pages in correct order in sev_gmem_post_populate() Jörg Rödel
2026-06-23 9:24 ` sashiko-bot
2026-06-23 9:30 ` Jörg Rödel
2026-06-23 12:56 ` Sean Christopherson
2026-06-23 9:15 ` [PATCH 3/4] KVM: guest_memfd: Add `write` parameter to kvm_gmem_populate() Jörg Rödel
2026-06-23 9:32 ` sashiko-bot [this message]
2026-06-23 12:57 ` Sean Christopherson
2026-06-23 9:15 ` [PATCH 4/4] kvm: sev: Acquire a writeable page reference for CPUID pages Jörg Rödel
2026-06-23 9:33 ` sashiko-bot
2026-06-23 14:36 ` Ackerley Tng
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=20260623093231.B4CA91F00A3A@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=joro@8bytes.org \
--cc=kvm@vger.kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.