From: Tom Lendacky <thomas.lendacky@amd.com>
To: Atish Patra <atish.patra@linux.dev>,
Sean Christopherson <seanjc@google.com>,
Paolo Bonzini <pbonzini@redhat.com>,
Borislav Petkov <bp@alien8.de>,
Dave Hansen <dave.hansen@linux.intel.com>,
x86@kernel.org, "H. Peter Anvin" <hpa@zytor.com>,
Peter Gonda <pgonda@google.com>,
Brijesh Singh <brijesh.singh@amd.com>,
Youngjae Lee <youngjaelee@meta.com>,
Ashish Kalra <ashish.kalra@amd.com>,
Michael Roth <michael.roth@amd.com>,
John Allen <john.allen@amd.com>,
Herbert Xu <herbert@gondor.apana.org.au>
Cc: clm@meta.com, kvm@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-crypto@vger.kernel.org, stable@vger.kernel.org,
Atish Patra <atishp@meta.com>, Sashiko <sashiko-bot@kernel.org>
Subject: Re: [PATCH v2 4/4] crypto: ccp: Fix memory leak in SEV INIT_EX path
Date: Tue, 2 Jun 2026 09:54:04 -0500 [thread overview]
Message-ID: <f57a427b-0fc8-41f6-bc3c-cd86e7812629@amd.com> (raw)
In-Reply-To: <20260601-sev_snp_fixes-v2-4-611891b28a86@meta.com>
On 6/1/26 18:04, Atish Patra wrote:
> From: Atish Patra <atishp@meta.com>
>
> allocated pages in _init_ext_path are never freed and sev_init_ex_buffer
> is left pointing at the leaked memory in case of any failures during the
> function..
>
> Fix by adding an error path that frees the pages and clears
> sev_init_ex_buffer. Make sure we only free the memory if the failure
> happens before the conversion. Otherwise, we may end up trying to free
> up converted pages in case of reclaim failure. rmp_mark_pages_firmware
> failures should be rare enough to avoid more code complexity to track
> down which pages were reclaimed/leaked vs which are not.
>
> Fixes: 7364a6fbca45 ("crypto: ccp: Handle non-volatile INIT_EX data when SNP is enabled")
>
> Reported-by: Sashiko <sashiko-bot@kernel.org>
> Signed-off-by: Atish Patra <atishp@meta.com>
Not sure the goto's are the best, but they do the job - just a personal
preference for me here.
The new comment below is a bit verbose, I would think it is sufficient to
just say something like "Pages can be in an inconsistent state, don't
release them back to the system" or such.
It might be nice in the future if we can identify if the reclaim was
successful and use that for determining whether the pages are safe to
freed... but the failure chance should be practically zero, so I'm not
sure it is worth it.
Reviewed-by: Tom Lendacky <thomas.lendacky@amd.com>
> ---
> drivers/crypto/ccp/sev-dev.c | 16 ++++++++++++++--
> 1 file changed, 14 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/crypto/ccp/sev-dev.c b/drivers/crypto/ccp/sev-dev.c
> index 3d4793e8e34b..8566f164430b 100644
> --- a/drivers/crypto/ccp/sev-dev.c
> +++ b/drivers/crypto/ccp/sev-dev.c
> @@ -1550,7 +1550,7 @@ static int __sev_platform_init_handle_init_ex_path(struct sev_device *sev)
>
> rc = sev_read_init_ex_file();
> if (rc)
> - return rc;
> + goto err_free;
>
> /* If SEV-SNP is initialized, transition to firmware page. */
> if (sev->snp_initialized) {
> @@ -1559,11 +1559,23 @@ static int __sev_platform_init_handle_init_ex_path(struct sev_device *sev)
> npages = 1UL << get_order(NV_LENGTH);
> if (rmp_mark_pages_firmware(__pa(sev_init_ex_buffer), npages, true)) {
> dev_err(sev->dev, "SEV: INIT_EX NV memory page state change failed.\n");
> - return -ENOMEM;
> + rc = -ENOMEM;
> + /*
> + * Don't free on conversion failure: the rollback may
> + * have left pages firmware-owned, and a high-order
> + * block can't be partially freed.
> + */
> + goto err_reset;
> }
> }
>
> return 0;
> +
> +err_free:
> + __free_pages(page, get_order(NV_LENGTH));
> +err_reset:
> + sev_init_ex_buffer = NULL;
> + return rc;
> }
>
> static int __sev_platform_init_locked(int *error)
>
next prev parent reply other threads:[~2026-06-02 14:54 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-01 23:04 [PATCH v2 0/4] KVM: Miscellaneous SEV/SNP related fixes Atish Patra
2026-06-01 23:04 ` [PATCH v2 1/4] KVM: SEV: Do not allow intra-host migration/mirroring of SNP VMs Atish Patra
2026-06-02 14:38 ` Tom Lendacky
2026-06-02 18:44 ` Atish Patra
2026-06-01 23:04 ` [PATCH v2 2/4] KVM: selftests: Verify SNP VMs are rejected from migration and mirroring Atish Patra
2026-06-01 23:04 ` [PATCH v2 3/4] crypto: ccp: Fix possible deadlock in SEV init failure path Atish Patra
2026-06-02 14:43 ` Tom Lendacky
2026-06-02 18:46 ` Atish Patra
2026-06-01 23:04 ` [PATCH v2 4/4] crypto: ccp: Fix memory leak in SEV INIT_EX path Atish Patra
2026-06-02 14:54 ` Tom Lendacky [this message]
2026-06-02 18:17 ` Atish Patra
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=f57a427b-0fc8-41f6-bc3c-cd86e7812629@amd.com \
--to=thomas.lendacky@amd.com \
--cc=ashish.kalra@amd.com \
--cc=atish.patra@linux.dev \
--cc=atishp@meta.com \
--cc=bp@alien8.de \
--cc=brijesh.singh@amd.com \
--cc=clm@meta.com \
--cc=dave.hansen@linux.intel.com \
--cc=herbert@gondor.apana.org.au \
--cc=hpa@zytor.com \
--cc=john.allen@amd.com \
--cc=kvm@vger.kernel.org \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=michael.roth@amd.com \
--cc=pbonzini@redhat.com \
--cc=pgonda@google.com \
--cc=sashiko-bot@kernel.org \
--cc=seanjc@google.com \
--cc=stable@vger.kernel.org \
--cc=x86@kernel.org \
--cc=youngjaelee@meta.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®