Re: [PATCH 3/4] kvm: svm: Support guest-provided VMSA for launching

["Jörg Rödel" <joro@8bytes.org>]

On Thu, Jun 11, 2026 at 01:05:36PM +0000, sashiko-bot@kernel.org wrote:
> [Severity: Critical]
> This is a pre-existing issue, but can unprivileged userspace panic the host
> kernel by punching a hole in the guest_memfd file backing the guest-provided
> VMSA pages?
> 
> Guest-provided VMSA pages are placed into the VMSA (Firmware) RMP state.
> However, KVM drops its page reference immediately after lookup:
> 
> arch/x86/kvm/svm/sev.c:sev_es_vmsa_pa() {
>     ...
>     kvm_release_page_clean(page);
>     ...
> }

There is at least not a reference counting issue here, as GMEM still holds a
reference to the page.

> If userspace triggers a page release, the page is freed by the core MM
> subsystem. During freeing, sev_gmem_invalidate() attempts to transition the
> page via rmp_make_shared(), which architecturally fails on VMSA-state pages:

Not sure about that, I havn't checked whether GMEM allows these kinds of
page-state changes before LAUNCH_FINISH. After LAUNCH_FINISH it is not problem
anymore because VMSA address in the VMCB does not point to a valid VMSA page,
then VMRUN will fail.

> [Severity: High]
> This is a pre-existing issue, but does KVM permanently leak successfully 
> launched SNP VM VMSA pages during VM teardown?
> 
> During normal teardown of an SNP guest, KVM attempts to transition its
> allocated VMSA pages to shared state via kvm_rmp_make_shared():
> 
> arch/x86/kvm/svm/sev.c:sev_es_vcpu_free_vmsa() {
>     ...
>     if (kvm_rmp_make_shared(vcpu->kvm, pfn, PG_LEVEL_4K)) {
>         pr_err("Failed to make VMSA page shared - leaking it to avoid re-use\n");
>         goto out;
>     }
>     ...
> }
> 
> kvm_rmp_make_shared() uses the RMPUPDATE instruction, which architecturally
> fails on pages that are in the VMSA state. The function detects the failure,
> logs the error, and permanently leaks the page. Because VMs are destroyed
> routinely, this will eventually exhaust host memory. KVM must use
> snp_page_reclaim() instead of kvm_rmp_make_shared() for pages in the VMSA
> state.

Wrong, VMSA pages are freed when they are KVM owned, when they are guest owned
they are freed via gmem. This is all fine if it happens after LAUNCH_FINISH and
no VCPU of the VM is still running.

> [Severity: High]
> Does this code call sev_es_vmsa_pa() without holding kvm->srcu or 
> kvm->slots_lock?
> 
> Looking at the execution path immediately following this comment in 
> snp_launch_update_vmsa():
> 
>         /* VMSA encrypted - put it into the VMCB */
>         svm->vmcb->control.vmsa_pa = sev_es_vmsa_pa(vcpu);
> 
> arch/x86/kvm/svm/sev.c:sev_es_vmsa_pa() {
>     ...
>     slot = gfn_to_memslot(vcpu->kvm, gfn);
>     ...
> }
> 
> gfn_to_memslot() dereferences the KVM memslots array. Since this is called 
> without SRCU or slots_lock, a concurrent thread executing 
> KVM_SET_USER_MEMORY_REGION can swap and free the memslots array while 
> gfn_to_memslot() is accessing it, leading to a use-after-free.

Not sure if this is an issue. If it is then it is pre-existing. I think the
worst that can happen is a failed VMRUN because the VMSAs become invalid, no?

-Joerg