From: sashiko-bot@kernel.org
To: "Sean Christopherson" <seanjc@google.com>
Cc: kvm@vger.kernel.org
Subject: Re: [PATCH v3 04/12] KVM: Rename .gmem_invalidate() to .gmem_reclaim_memory()
Date: Tue, 30 Jun 2026 22:39:32 +0000 [thread overview]
Message-ID: <20260630223933.1E5191F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260630222607.497895-5-seanjc@google.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [Critical] Failure to leak a page after an RMP transition error in sev_gmem_reclaim_memory allows hypervisor-owned pages to be unsafely returned to the host page allocator.
--
commit c2f5753d0289e9cb80f17e6494a0d03b0f6a529a
Author: Sean Christopherson <seanjc@google.com>
KVM: Rename .gmem_invalidate() to .gmem_reclaim_memory()
Rename the .gmem_invalidate() hook to .gmem_reclaim_memory() since it is
called when a folio is freed, which is too late to invalidate memory usage.
Keep guest_memfd's trampoline and opportunistically guard the callback with
an ifdef.
> diff --git a/arch/x86/kvm/svm/sev.c b/arch/x86/kvm/svm/sev.c
> index 30792adcfc8e5..4465e75494f2d 100644
> --- a/arch/x86/kvm/svm/sev.c
> +++ b/arch/x86/kvm/svm/sev.c
> @@ -5136,7 +5136,7 @@ int sev_gmem_prepare(struct kvm *kvm, kvm_pfn_t pfn, gfn_t gfn, int max_order)
> return 0;
> }
>
> -void sev_gmem_invalidate(kvm_pfn_t start, kvm_pfn_t end)
> +void sev_gmem_reclaim_memory(kvm_pfn_t start, kvm_pfn_t end)
> {
[Severity: Critical]
This is a pre-existing issue, but does failing to leak the page on RMP update
errors allow it to be unsafely returned to the host allocator?
In sev_gmem_reclaim_memory(), if rmp_make_shared() fails, the code logs a
warning and proceeds to the next PFN:
rc = rmp_make_shared(pfn, use_2m_update ? PG_LEVEL_2M : PG_LEVEL_4K);
if (WARN_ONCE(rc, "SEV: Failed to update RMP entry ..."))
goto next_pfn;
By jumping to next_pfn instead of calling snp_leak_pages(), the
hypervisor-owned page could be freed back to the host allocator.
Could this trigger a hardware RMP violation and a host panic upon the page's
next use? A later patch in the series fixes a guest-triggerable vector for
this failure, but the structural issue remains.
> kvm_pfn_t pfn;
>
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260630222607.497895-1-seanjc@google.com?part=4
next prev parent reply other threads:[~2026-06-30 22:39 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-30 22:25 [PATCH v3 00/12] KVM: SEV: Fix RMP #PF due to freeing in-use VMSA Sean Christopherson
2026-06-30 22:25 ` [PATCH v3 01/12] KVM: SEV: Track the GPA of the guest-controlled VMSA used for SNP guests Sean Christopherson
2026-07-01 19:33 ` Michael Roth
2026-06-30 22:25 ` [PATCH v3 02/12] KVM: SEV: Extract loading of guest-provided VMSA to a separate helper Sean Christopherson
2026-07-01 19:34 ` Michael Roth
2026-06-30 22:25 ` [PATCH v3 03/12] KVM: SEV: Mark vCPU RUNNABLE after AP_CREATE, even if VMSA is unusable Sean Christopherson
2026-07-01 19:36 ` Michael Roth
2026-06-30 22:25 ` [PATCH v3 04/12] KVM: Rename .gmem_invalidate() to .gmem_reclaim_memory() Sean Christopherson
2026-06-30 22:39 ` sashiko-bot [this message]
2026-07-01 19:41 ` Michael Roth
2026-06-30 22:26 ` [PATCH v3 05/12] KVM: x86: Serialize writes to disabled_quirks using kvm->lock Sean Christopherson
2026-07-01 21:59 ` Michael Roth
2026-06-30 22:26 ` [PATCH v3 06/12] KVM: x86: Ensure runtime reads of disabled_quirks are resolved once Sean Christopherson
2026-07-01 22:00 ` Michael Roth
2026-06-30 22:26 ` [PATCH v3 07/12] KVM: x86/mmu: Fold kvm_mmu_zap_memslot() into kvm_arch_flush_shadow_memslot() Sean Christopherson
2026-07-01 22:04 ` Michael Roth
2026-06-30 22:26 ` [PATCH v3 08/12] KVM: x86/mmu: Split kvm_mmu_zap_all_fast() into "front" and "back" halves Sean Christopherson
2026-07-01 22:07 ` Michael Roth
2026-06-30 22:26 ` [PATCH v3 09/12] KVM: x86/mmu: Use split "zap all fast" helpers when invalidating memslot Sean Christopherson
2026-07-01 22:19 ` Michael Roth
2026-06-30 22:26 ` [PATCH v3 10/12] KVM: SEV: Forcefully invalidate SNP VMSA if its backing gmem page is zapped Sean Christopherson
2026-07-01 21:56 ` Michael Roth
2026-06-30 22:26 ` [PATCH v3 11/12] KVM: x86: Guard .gmem_prepare() declarations with HAVE_KVM_GMEM_PREPARE=y Sean Christopherson
2026-07-01 22:42 ` Michael Roth
2026-07-06 23:16 ` Sean Christopherson
2026-06-30 22:26 ` [PATCH v3 12/12] KVM: SEV: Mark vCPU has having guest-provided VMSA even if its invalid Sean Christopherson
2026-07-01 22:47 ` Michael Roth
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=20260630223933.1E5191F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=kvm@vger.kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
--cc=seanjc@google.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 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.