All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Ackerley Tng" <ackerleytng@google.com>
Cc: "Oliver Upton" <oupton@kernel.org>,
	kvmarm@lists.linux.dev, "Marc Zyngier" <maz@kernel.org>,
	kvm@vger.kernel.org
Subject: Re: [PATCH 2/4] KVM: SEV: Drop page refcount early during RMP fault handling
Date: Tue, 18 Aug 2026 08:26:19 +0000	[thread overview]
Message-ID: <20260818082620.722031F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260818-gmem-no-return-page-v1-2-4f8d939efdbc@google.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Critical] Dropping the page reference early exposes the physical frame (PFN) to concurrent freeing and reallocation before hardware RMP operations (PSMASH) execute, leading to cross-VM memory corruption.
--

--- Patch [2]: [PATCH 2/4] KVM: SEV: Drop page refcount early during RMP fault handling ---
commit b722a12d672bd9f9b3789be73ead1445ff086955
Author: Ackerley Tng <ackerleytng@google.com>

KVM: SEV: Drop page refcount early during RMP fault handling

This patch modifies the RMP fault handler to drop the page reference retrieved
from guest_memfd early. The intention is to avoid holding the reference
throughout the rest of the handler, as the subsequent hardware operations and
page table zapping only require the physical frame number.

> diff --git a/arch/x86/kvm/svm/sev.c b/arch/x86/kvm/svm/sev.c
> index b2738362a928b..19c31fa944e34 100644
> --- a/arch/x86/kvm/svm/sev.c
> +++ b/arch/x86/kvm/svm/sev.c
[ ... ]
> @@ -5036,12 +5036,13 @@ void sev_handle_rmp_fault(struct kvm_vcpu *vcpu, gpa_t gpa, u64 error_code)
>  				    gpa);
>  		return;
>  	}
> +	kvm_release_page_unused(page);
>  
>  	ret = snp_lookup_rmpentry(pfn, &assigned, &rmp_level);

[Severity: Critical]
Does dropping this page reference early expose the physical frame to concurrent
freeing and reallocation before the hardware operations execute?

Since sev_handle_rmp_fault() does not hold kvm->mmu_lock, if the page is
unpinned here, couldn't a concurrent fallocate(FALLOC_FL_PUNCH_HOLE) on the
guest_memfd unmap and free the page back to the host?

If the host then reallocates this physical page to a different VM as a
private 2MB hugepage, its reverse map entry would be assigned to the new VM.

When this vCPU resumes, it could call snp_lookup_rmpentry(), see the page is
assigned and 2MB, and proceed to execute snp_rmptable_psmash():

    if (rmp_level == PG_LEVEL_4K)
        goto out;

    ret = snp_rmptable_psmash(pfn);

Could this blindly shatter the other VM's 2MB entry into 4KB entries and
break hardware memory isolation?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260818-gmem-no-return-page-v1-0-4f8d939efdbc@google.com?part=2

  parent reply	other threads:[~2026-08-18  8:26 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-18  8:12 [PATCH 0/4] Stop returning struct page from guest_memfd PFN lookup Ackerley Tng
2026-08-18  8:12 ` [PATCH 1/4] KVM: SEV: Treat unassigned RMP entry as benign race on PSMASH failure Ackerley Tng
2026-08-18  8:23   ` sashiko-bot
2026-08-18  8:12 ` [PATCH 2/4] KVM: SEV: Drop page refcount early during RMP fault handling Ackerley Tng
2026-08-18  8:12   ` Yan Zhao
2026-08-18  9:04     ` Ackerley Tng
2026-08-18  8:26   ` sashiko-bot [this message]
2026-08-18  8:12 ` [PATCH 3/4] KVM: SEV: Drop page refcount early in VMSA reload Ackerley Tng
2026-08-18  8:12 ` [PATCH 4/4] KVM: guest_memfd: Stop returning struct page from PFN lookup Ackerley Tng
2026-08-18  8:34   ` Yan Zhao
2026-08-18  9:44     ` 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=20260818082620.722031F000E9@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=ackerleytng@google.com \
    --cc=kvm@vger.kernel.org \
    --cc=kvmarm@lists.linux.dev \
    --cc=maz@kernel.org \
    --cc=oupton@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.