Re: [PATCH v4 02/18] KVM: SEV: Extract loading of guest-provided VMSA to a separate helper

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:

Pre-existing issues:
- [Critical] Missing MMU invalidation sequence check and invalidation hooks when resolving and installing the guest memory PFN into the hardware VMCB (`vmsa_pa`), allowing a guest to trigger a host Use-After-Free via hole-punching.
- [High] Early return on failure to retrieve or load the VMSA PFN leaves the vCPU permanently in the `KVM_MP_STATE_HALTED` state, causing KVM_RUN to hang indefinitely instead of returning an error to userspace.
--

--- Patch [2]: [PATCH v4 02/18] KVM: SEV: Extract loading of guest-provided VMSA to a separate helper ---
commit 77b2286f40978a436ebf37446c67270e552074af
Author: Sean Christopherson <seanjc@google.com>

KVM: SEV: Extract loading of guest-provided VMSA to a separate helper

Extract the loading/retrieval of a guest-provided VMSA to a separate helper
so that KVM can reuse the core logic when refreshing the VMSA after an MMU
invalidation from guest_memfd.

Cc: stable@vger.kernel.org # 6.12.x

> diff --git a/arch/x86/kvm/svm/sev.c b/arch/x86/kvm/svm/sev.c
> index 827f5dc061023..d8ed00f76aa31 100644
> --- a/arch/x86/kvm/svm/sev.c
> +++ b/arch/x86/kvm/svm/sev.c
[ ... ]
> @@ -4011,12 +3999,9 @@ static void sev_snp_init_protected_guest_state(struct kvm_vcpu *vcpu)
>  	 */
>  	vmcb_mark_all_dirty(svm->vmcb);
>  
> -	if (!VALID_PAGE(svm->sev_es.snp_pending_vmsa_gpa))
> +	if (!VALID_PAGE(gpa))
>  		return;
>  
> -	gfn = gpa_to_gfn(svm->sev_es.snp_pending_vmsa_gpa);
> -	svm->sev_es.snp_pending_vmsa_gpa = INVALID_PAGE;
> -
>  	slot = gfn_to_memslot(vcpu->kvm, gfn);
>  	if (!slot)
>  		return;

[Severity: High]
This is a pre-existing issue, but if the VMSA loading fails here (e.g., due
to an invalid GPA or missing memslot), does the vCPU remain permanently
locked in KVM_MP_STATE_HALTED?

Since sev_snp_init_protected_guest_state() marks the vCPU as HALTED before
calling this reload helper, returning early bypasses the eventual transition
to KVM_MP_STATE_RUNNABLE. Could this cause KVM_RUN to hang indefinitely
instead of safely returning an error to userspace?

[ ... ]
> @@ -4040,7 +4025,7 @@ static void sev_snp_init_protected_guest_state(struct kvm_vcpu *vcpu)
>  	svm->sev_es.snp_has_guest_vmsa = true;
>  
>  	/* Use the new VMSA */
> -	svm->sev_es.snp_guest_vmsa_gpa = gfn_to_gpa(gfn);
> +	svm->sev_es.snp_guest_vmsa_gpa = gpa;
>  	svm->vmcb->control.vmsa_pa = pfn_to_hpa(pfn);

[Severity: Critical]
This isn't a bug introduced by this patch, but does resolving and installing
the PFN directly into the hardware VMCB (vmsa_pa) without using the
mmu_invalidate_seq retry protocol allow a guest to trigger a host
use-after-free?

If an untrusted guest triggers AP creation with a guest_memfd-backed VMSA,
and then punches a hole in that guest_memfd, could KVM miss the concurrent
invalidation since this path doesn't check the invalidation sequence under
kvm->mmu_lock? The hardware might continue using and writing to the freed
page.

>  
>  	/* Mark the vCPU as runnable */
> @@ -4054,6 +4039,31 @@ static void sev_snp_init_protected_guest_state(struct kvm_vcpu *vcpu)
>  	kvm_release_page_clean(page);
>  }

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260709204948.1988414-1-seanjc@google.com?part=2