Re: [PATCH 2/4] kvm: svm: Defer VMSA allocation to LAUNCH_FINISH stage

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

On Thu, Jun 11, 2026 at 12:58:13PM +0000, sashiko-bot@kernel.org wrote:
> [Severity: Medium]
> Does this error path leak the newly allocated VMSA?
> 
> Since sev_es_sync_vmsa() now allocates the VMSA, if
> sev_es_vcpu_vmsa_make_private() fails, the code returns via the "out" label
> without freeing the VMSA or resetting its state.
> 
> If userspace retries the KVM_SEV_SNP_LAUNCH_FINISH ioctl, sev_es_sync_vmsa()
> is called again and will trigger the WARN_ON_ONCE() in
> sev_es_vcpu_alloc_vmsa() because the state is still VMSA_SHARED:
> 
>     if (WARN_ON_ONCE(svm->sev_es.vmsa.vmsa_state != VMSA_NONE))
>         return -EINVAL;
> 
> Can we add a call to sev_es_vcpu_free_vmsa() on this error path?

Yes, this is a user-space triggerable WARN_ON_ONCE. Usually user-space does not
re-issue a LAUNCH_FINISHED command after it failed and doing so is not
supported to lead to anything productive anyway. The right fix is to remove the
WARN_ON_ONCE().

> [Severity: Medium]
> Does removing this allocation lead to KVM's INVALID_PAGE sentinel being passed
> to the PSP firmware?
> 
> If userspace creates a vCPU after the SEV-ES or SEV-SNP launch sequence has
> completed, the new vCPU's VMSA is never allocated.
> 
> When this vCPU is run, sev_es_vmsa_pa() returns KVM's INVALID_PAGE sentinel
> (~0ull), which is loaded into the VMCB, triggering an immediate #VMEXIT
> (SVM_EXIT_ERR).
> 
> If the dump_invalid_vmcb parameter is enabled, KVM handles this by calling
> dump_vmcb(), which then calls sev_decrypt_vmsa(). Since sev_es_vmsa_ref()
> returns NULL for VMSA_NONE, sev_decrypt_vmsa() erroneously assumes the VMSA
> is encrypted and passes the INVALID_PAGE sentinel directly to the PSP
> firmware as the source physical address for SEV_CMD_DBG_DECRYPT:
> 
>     data.src_addr = svm->vmcb->control.vmsa_pa;
>     data.len = PAGE_SIZE;
> 
>     ret = sev_issue_cmd(vcpu->kvm, SEV_CMD_DBG_DECRYPT, &data, &argp_err);
> 
> Could this direct hardware exposure to an invalid page address risk firmware
> hangs or IOMMU faults?

This is not true. The VMSAs are allocated in sev_es_sync_vmsa() for both SEV-ES
and SEV-SNP guests. Both code path also propagate the VMSA into the VMCB before
LAUNCH_FINISH is complete and the VM can be invoked.

-Joerg