Kernel KVM virtualization development
 help / color / mirror / Atom feed
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

  reply	other threads:[~2026-06-30 22:39 UTC|newest]

Thread overview: 26+ 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-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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox