Re: [PATCH v4 03/18] KVM: SEV: Mark vCPU RUNNABLE after AP_CREATE, even if VMSA is unusable

[sashiko-bot@kernel.org]

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

New issues:
- [High] KVM incorrectly executes VMRUN with a dummy unmeasured host VMSA instead of failing KVM_RUN when a vCPU's initial AP_CREATE VMSA load fails.

Pre-existing issues:
- [Critical] sev_snp_reload_vmsa() bypasses the MMU notifier invalidation retry protocol, leading to a Use-After-Free of a physical page if a concurrent guest_memfd invalidation occurs.
--

--- Patch [3]: [PATCH v4 03/18] KVM: SEV: Mark vCPU RUNNABLE after AP_CREATE, even if VMSA is unusable ---
commit ca23b8314664c0ed691814678164a510162e2299
Author: Sean Christopherson <seanjc@google.com>

KVM: SEV: Mark vCPU RUNNABLE after AP_CREATE, even if VMSA is unusable

This commit marks a vCPU as RUNNABLE after responding to an AP_CREATE
request, even if the guest-specified VMSA is unusable. This prevents the
vCPU from hanging in a non-running state and instead allows KVM_RUN to
return an error to userspace. It also enables retrying the VMSA load in
the future.

> diff --git a/arch/x86/kvm/svm/sev.c b/arch/x86/kvm/svm/sev.c
> index d8ed00f76aa31..30792adcfc8e5 100644
> --- a/arch/x86/kvm/svm/sev.c
> +++ b/arch/x86/kvm/svm/sev.c
> @@ -4028,9 +4028,6 @@ static void sev_snp_reload_vmsa(struct kvm_vcpu *vcpu, gpa_t gpa)
>  	svm->sev_es.snp_guest_vmsa_gpa = gpa;
>  	svm->vmcb->control.vmsa_pa = pfn_to_hpa(pfn);

[Severity: Critical]
This is a pre-existing issue, but does sev_snp_reload_vmsa() bypass the
MMU notifier invalidation retry protocol here?

If a concurrent PUNCH_HOLE occurs on the guest_memfd while
sev_snp_reload_vmsa() fetches and installs a guest VMSA, this could lead
to a use-after-free of the physical page.

sev_snp_reload_vmsa() resolves the PFN via kvm_gmem_get_pfn() and directly
installs it into svm->vmcb->control.vmsa_pa without holding kvm->mmu_lock
or checking mmu_invalidate_retry_gfn(). It then drops the page reference.

If the page is subsequently freed by guest_memfd, KVM would retain the
stale physical address in vmsa_pa, and the hardware could write guest state
to the freed page during VMRUN.

> -	/* Mark the vCPU as runnable */
> -	kvm_set_mp_state(vcpu, KVM_MP_STATE_RUNNABLE);
> -

[ ... ]

> @@ -4062,6 +4059,15 @@ static void sev_snp_init_protected_guest_state(struct kvm_vcpu *vcpu)
>  	svm->sev_es.snp_pending_vmsa_gpa = INVALID_PAGE;
>  
>  	sev_snp_reload_vmsa(vcpu, gpa);
> +
> +	/*
> +	 * Mark the vCPU as runnable for CREATE requests, indicated by a valid
> +	 * VMSA GPA, even if installing the VMSA failed, so that KVM_RUN will
> +	 * fail instead of blocking indefinitely and hanging the vCPU, e.g. if
> +	 * the backing guest_memfd page is unavailable.
> +	 */
> +	if (VALID_PAGE(gpa))
> +		kvm_set_mp_state(vcpu, KVM_MP_STATE_RUNNABLE);

[Severity: High]
Does this allow KVM to incorrectly execute VMRUN with a dummy unmeasured
host VMSA when the initial AP_CREATE VMSA load fails?

If a guest issues an AP_CREATE request with an invalid VMSA (such as having
no backing guest_memfd page) for a vCPU that has not yet successfully loaded
a guest VMSA, marking it RUNNABLE is intended to make pre_sev_run() fail
KVM_RUN.

However, because snp_has_guest_vmsa remains false on failure,
sev_es_init_vmcb() overwrites the INVALID_PAGE state with the KVM-allocated
fallback VMSA physical address:

	if (!svm->sev_es.snp_has_guest_vmsa) {
		if (svm->sev_es.vmsa)
			svm->vmcb->control.vmsa_pa = __pa(svm->sev_es.vmsa);
		else
			svm->vmcb->control.vmsa_pa = INVALID_PAGE;
	}

Because of this, pre_sev_run() will see a valid vmsa_pa and pass:

	if (is_sev_es_guest(vcpu) && !VALID_PAGE(svm->vmcb->control.vmsa_pa))
		return -EINVAL;

Will this result in a hardware RMP violation or guest state corruption when
KVM attempts VMRUN with the dummy VMSA?

>  }

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