From nobody Mon Jun 15 06:35:44 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 73B043D4129; Wed, 8 Apr 2026 14:34:05 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775658845; cv=none; b=KLedsJAATK8/urHZ4ntjJJ2gv5+pe9A7RAXChpKMSo2XtdaeSN26tbSmTyMOwoWId4cDFihhI7LAiVunqtk9g3WX+ri0OXu/WwMoa1CHaI/PaJ6I0FIVqO6ieOJtMoyMf/Hb0U4ZjE0dSvJkYA5pL8bjqd+tZBD9eXW23ZN5hwA= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775658845; c=relaxed/simple; bh=zLOyvLtj9bTMX8CGZAIXsO+GTfPSYgI63sCvH3xxgSc=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=pdVzeKjU546fH57qqrkjmlMA+iXg6gILooHIw5SZ3BeRC0YT6g2FEsnxCOZMDtDHoM33BuYLeOVkuxf5JaklhuBRh4dLQuMNka+14VyO82D1syOMCgyVhElITRrvfuHZ3lxVZ99oWgKqE2iyOD8EkNHJZROIrVqNNmiKPkRBvJQ= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=vPpvVVjd; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="vPpvVVjd" Received: by smtp.kernel.org (Postfix) with ESMTPSA id A22B4C19424; Wed, 8 Apr 2026 14:34:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1775658845; bh=zLOyvLtj9bTMX8CGZAIXsO+GTfPSYgI63sCvH3xxgSc=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=vPpvVVjdGxEhmJZmspFokRd9+HQbHkBuLmtE/3GzdpOD67xQF5GHSZrjWgO0BSXdW iwuG2UHcHnlJv9Dlz7jz9Dw2q9TBhkTXZKJMMqHyftaG1KaVApqSTyAM5MOpyL5AK1 Qia/kLPcP308jaLXqUfknd0R/6FxQRpYT3XV4mBCGAx7IE6/WHm8h5fweFPvcJNmJf tsDTbJCKd+HCccRbPoEHuq52/4vd1dQs0tkcRpZi/ud4ofxrrymGVsKVy9u3bfX8FZ avaWq5E+bAbbIIHEuCMLtU1XHcDSI1mNBstqHBIS12ps5OI+QBtSqw8Hr2WeUTfRzV vpDMQ1oEWNOLw== From: Tycho Andersen To: Tom Lendacky , John Allen , Herbert Xu , "David S. Miller" , Ashish Kalra Cc: "Borislav Petkov (AMD)" , linux-crypto@vger.kernel.org, linux-kernel@vger.kernel.org, Brijesh Singh , Michael Roth , Alexey Kardashevskiy , Dan Williams , "Tycho Andersen (AMD)" Subject: [PATCH v1 1/4] crypto/ccp: Reverse the cleanup order in psp_dev_destroy() Date: Wed, 8 Apr 2026 08:32:56 -0600 Message-ID: <20260408143259.602767-2-tycho@kernel.org> X-Mailer: git-send-email 2.53.0 In-Reply-To: <20260408143259.602767-1-tycho@kernel.org> References: <20260408143259.602767-1-tycho@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: "Tycho Andersen (AMD)" Before SNP x86 shutdown [1], all HV_FIXED pages were always leaked on module unload. Now pages can be reclaimed if they are freed before SNP shutdown. The SFS driver does sfs_dev_destroy() -> snp_free_hv_fixed_pages(), marking the command buffer as free. But this happens after sev_dev_destroy() in psp_dev_destroy(), so the pages are always leaked. Rearrange psp_dev_destroy() to destroy things in the reverse order from psp_init(), so that any dependencies can be unwound accordingly. This lets SFS free the page and the subsequent SNP shutdown release it. This was identified with use of Chris Mason's review-prompts: https://github.com/masoncl/review-prompts [1]: https://lore.kernel.org/all/20260324161301.1353976-1-tycho@kernel.org/ Fixes: 648dbccc03a0 ("crypto: ccp - Add AMD Seamless Firmware Servicing (SF= S) driver") Reported-by: review-prompts Assisted-by: Claude:claude-4.6-opus Suggested-by: Tom Lendacky Signed-off-by: Tycho Andersen (AMD) Reviewed-by: Ashish Kalra Reviewed-by: Tom Lendacky --- drivers/crypto/ccp/psp-dev.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/crypto/ccp/psp-dev.c b/drivers/crypto/ccp/psp-dev.c index 5c7f7e02a7d8..b14ce51065d5 100644 --- a/drivers/crypto/ccp/psp-dev.c +++ b/drivers/crypto/ccp/psp-dev.c @@ -316,15 +316,15 @@ void psp_dev_destroy(struct sp_device *sp) if (!psp) return; =20 - sev_dev_destroy(psp); + dbc_dev_destroy(psp); =20 - tee_dev_destroy(psp); + platform_access_dev_destroy(psp); =20 sfs_dev_destroy(psp); =20 - dbc_dev_destroy(psp); + tee_dev_destroy(psp); =20 - platform_access_dev_destroy(psp); + sev_dev_destroy(psp); =20 sp_free_psp_irq(sp, psp); =20 --=20 2.53.0 From nobody Mon Jun 15 06:35:44 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id D89FD3D3D03; Wed, 8 Apr 2026 14:34:06 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775658846; cv=none; b=kg1L1XlhV8k7rUHPCYKN288wSADOcpk//42wZJRyNkc1wkUkdgJBrYexR+4EoTIEsWIFoxpOJ+RhyO7y722KNV/X6kJHFR3JXaFoa+Ln7E/tJ/j+9fOnyZ4Cu6bAegyno5xLGD8VrFmICeuRpcIw3YBLaEgyqCBu/Zr2fr0XoLQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775658846; c=relaxed/simple; bh=eqeiAcPNJoTSStYt75yr4ts6fdSk7s1G6BqcIV2sk3A=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=CChm55ealw3fWp4xUv16KOfsiDwaW4FRb9wf/uFTygOP1JNBQ6B0+TMXa9vTNaXM0KcZVAYR8c+2OBv3R0lXowHvix2pdKruYoNTCxdW9C4ErsH7By3ONiazXWD81CSB5Mz93pJRoVgvPn/YEZmqQzPnvCbc15CgbUh7aR2AZ+8= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=p+09DSAs; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="p+09DSAs" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 52616C2BC87; Wed, 8 Apr 2026 14:34:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1775658846; bh=eqeiAcPNJoTSStYt75yr4ts6fdSk7s1G6BqcIV2sk3A=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=p+09DSAsZv+juc5pNeg+j9ihUj/dDi0Hrufvk3YCYrzYs2aJzJ21EKC85zfI5wXL3 DN7NP9D6R+cOIEMrRkeTyF9gT7cmFBwaLtABrQkC+v7Rqz5J1tqZlaETtb4jtkdzc5 GHYQNPACKEUdqY42xF3FuVD/9blljao8uwxa0SfNbRAfP4U5L50A1uGGgltloirsNB 7SujRG52zbKb1KkaJd/ah5Ga58sKU5YJ8ABbmF9BkAH4tgFYFyl1ZvyBlUleqZNbKW OqW7vXCi5VOybUgyQ/Qh8XyoEzCloiyjnPn2Lr0g3kcyH9QOQjFndTo/MHKgZbJ2nj DY+ykkLl3Yj9g== From: Tycho Andersen To: Tom Lendacky , John Allen , Herbert Xu , "David S. Miller" , Ashish Kalra Cc: "Borislav Petkov (AMD)" , linux-crypto@vger.kernel.org, linux-kernel@vger.kernel.org, Brijesh Singh , Michael Roth , Alexey Kardashevskiy , Dan Williams , "Tycho Andersen (AMD)" Subject: [PATCH v1 2/4] crypto/ccp: Fix snp_filter_reserved_mem_regions() off-by-one Date: Wed, 8 Apr 2026 08:32:57 -0600 Message-ID: <20260408143259.602767-3-tycho@kernel.org> X-Mailer: git-send-email 2.53.0 In-Reply-To: <20260408143259.602767-1-tycho@kernel.org> References: <20260408143259.602767-1-tycho@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: "Tycho Andersen (AMD)" Sashiko notes: > regarding the bounds check in snp_filter_reserved_mem_regions() > called via walk_iomem_res_desc(): does the check > if ((range_list->num_elements * 16 + 8) > PAGE_SIZE) > allow an off-by-one heap buffer overflow? > > If range_list->num_elements is 255, 255 * 16 + 8 =3D 4088, which is <=3D = 4096. > Writing range->base (8 bytes) fills 4088-4095, but writing range->page_co= unt > (4 bytes) would write to 4096-4099, overflowing the kzalloc-allocated > PAGE_SIZE buffer. Fix this by accounting for the entry about to be written to, in addition to the entries that are already allocated. Fixes: 1ca5614b84ee ("crypto: ccp: Add support to initialize the AMD-SP for= SEV-SNP") Reported-by: Sashiko Assisted-by: Gemini:gemini-3.1-pro-preview Link: https://sashiko.dev/#/patchset/20260324161301.1353976-1-tycho%40kerne= l.org Signed-off-by: Tycho Andersen (AMD) Reviewed-by: Tom Lendacky --- drivers/crypto/ccp/sev-dev.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/drivers/crypto/ccp/sev-dev.c b/drivers/crypto/ccp/sev-dev.c index 939fa8aa155c..e87efcff8df2 100644 --- a/drivers/crypto/ccp/sev-dev.c +++ b/drivers/crypto/ccp/sev-dev.c @@ -1328,10 +1328,11 @@ static int snp_filter_reserved_mem_regions(struct r= esource *rs, void *arg) size_t size; =20 /* - * Ensure the list of HV_FIXED pages that will be passed to firmware - * do not exceed the page-sized argument buffer. + * Ensure the list of HV_FIXED pages passed to the firmware including + * the one about to be written to do not exceed the page-sized argument + * buffer. */ - if ((range_list->num_elements * sizeof(struct sev_data_range) + + if (((range_list->num_elements + 1) * sizeof(struct sev_data_range) + sizeof(struct sev_data_range_list)) > PAGE_SIZE) return -E2BIG; =20 --=20 2.53.0 From nobody Mon Jun 15 06:35:44 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C9E063D47B1; Wed, 8 Apr 2026 14:34:08 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775658848; cv=none; b=nUKRMAF3O4cL9+aKHoLVx84uAxZCH4ZWpEj6dmoMKARFgB/UkfzBkieeYzmWHD8J47Kp2h0TgPZdcG5Q/Q2d+EkjQgxCWyDChWebFVQNWMuGdWIv/hfiWAd1qCUxsC3pRIkmyJJt5sb0lzO2xY4fnMywxevHErCJxv7EMZpQI30= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775658848; c=relaxed/simple; bh=HlbJlPHaIqGCg+7KyVe8KtzjmCdZxRsgKdRGK1QZLxk=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=E88aSGJDqUnD7la4lvfE/FpEyQO9liHNtajYFYq/8LwKVAHStp7JYV4uvRWYyGJKk35zl3PhtEmyrX/YoahlxD0SBXaRKodKhrf4jxBNrvLGDsGBf309pcqUFk54x/HCjmkYl+Zq5iosQgTjhk5aX1nhIkHHPpSlYRVAWcufiWc= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=BSSZrGLM; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="BSSZrGLM" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0204AC19424; Wed, 8 Apr 2026 14:34:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1775658848; bh=HlbJlPHaIqGCg+7KyVe8KtzjmCdZxRsgKdRGK1QZLxk=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=BSSZrGLM352kFRI7kNegSvnCR+mKenmeoIKbP9CtVkz8xOMItrHmQn8az3eAu/FE7 2Wqf+J75X6VPwBNaCgidTzH4d7Cgnkk2iaISEQaUINVRdkDYfUcCKEC3MSuW4WkWof lTj8s8yUwxM7lih5HAz9oY07VHpNBJ9p/7yUQ9IWx4S2YinkQ2pKcnoKGcEHMtBrF3 gXQuAijpGpg2yg7fyQspMd2J7t8gfX1CetT7xdONPaA6+k44TMm+kHu2MF87uC1yhC kUQplrzYtM+Hhv73kdvEm7E7Ydj9qiog80Sm7eTN1BrrbOHdoQMQWCySG7Hc51skjg nbKM4WIAz2yKg== From: Tycho Andersen To: Tom Lendacky , John Allen , Herbert Xu , "David S. Miller" , Ashish Kalra Cc: "Borislav Petkov (AMD)" , linux-crypto@vger.kernel.org, linux-kernel@vger.kernel.org, Brijesh Singh , Michael Roth , Alexey Kardashevskiy , Dan Williams , "Tycho Andersen (AMD)" Subject: [PATCH v1 3/4] crypto/ccp: Check for page allocation failure correctly in TIO Date: Wed, 8 Apr 2026 08:32:58 -0600 Message-ID: <20260408143259.602767-4-tycho@kernel.org> X-Mailer: git-send-email 2.53.0 In-Reply-To: <20260408143259.602767-1-tycho@kernel.org> References: <20260408143259.602767-1-tycho@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: "Tycho Andersen (AMD)" Sashiko notes: > if __snp_alloc_firmware_pages() returns NULL under memory pressure, is it > safe to pass it directly to page_address()? > > On architectures without HASHED_PAGE_VIRTUAL, page_address(NULL) might > compute a deterministic but invalid, non-zero virtual address. The > subsequent if (tio_status) check would then evaluate to true, and > sev_tsm_init_locked() would dereference the invalid pointer. Indeed, page_address(NULL) will return non-NULL garbage here. Fix this by checking the page allocation itself for NULL, not the resulting virtual address. Fixes: 4be423572da1 ("crypto/ccp: Implement SEV-TIO PCIe IDE (phase1)") Reported-by: Sashiko Assisted-by: Gemini:gemini-3.1-pro-preview Link: https://sashiko.dev/#/patchset/20260324161301.1353976-1-tycho%40kerne= l.org Signed-off-by: Tycho Andersen (AMD) Reviewed-by: Tom Lendacky --- drivers/crypto/ccp/sev-dev.c | 12 ++++++++---- 1 file changed, 8 insertions(+), 4 deletions(-) diff --git a/drivers/crypto/ccp/sev-dev.c b/drivers/crypto/ccp/sev-dev.c index e87efcff8df2..11e2c667c0ad 100644 --- a/drivers/crypto/ccp/sev-dev.c +++ b/drivers/crypto/ccp/sev-dev.c @@ -1488,6 +1488,8 @@ static int __sev_snp_init_locked(int *error, unsigned= int max_snp_asid) &snp_panic_notifier); =20 if (data.tio_en) { + struct page *page; + /* * This executes with the sev_cmd_mutex held so down the stack * snp_reclaim_pages(locked=3Dfalse) might be needed (which is extremely @@ -1495,12 +1497,14 @@ static int __sev_snp_init_locked(int *error, unsign= ed int max_snp_asid) * Instead of exporting __snp_alloc_firmware_pages(), allocate a page * for this one call here. */ - void *tio_status =3D page_address(__snp_alloc_firmware_pages( - GFP_KERNEL_ACCOUNT | __GFP_ZERO, 0, true)); + page =3D __snp_alloc_firmware_pages(GFP_KERNEL_ACCOUNT | __GFP_ZERO, + 0, true); + if (page) { + void *tio_status =3D page_address(page); =20 - if (tio_status) { sev_tsm_init_locked(sev, tio_status); - __snp_free_firmware_pages(virt_to_page(tio_status), 0, true); + + __snp_free_firmware_pages(page, 0, true); } } =20 --=20 2.53.0 From nobody Mon Jun 15 06:35:44 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 782A63D5256; Wed, 8 Apr 2026 14:34:10 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775658850; cv=none; b=TM4S+9m79ccdyV0ga6YMKlUOCOe+YTEV9EmaPpQr2U7V5Ow3ZavfyxKwL2BZxfd9fciDTtGll1t+9uOjKvvXPU+fN7QntldR4aQMyJijJOzYCrsCX6nMco7mEsBMpz84Kt/OQWVfqbiMJwQhMvaOJNG4VfyPKgz1yNO3XMoeZhg= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775658850; c=relaxed/simple; bh=MtGTjVVC+mLYgJUWL3jI+tDSobLQGokRrpe7RX8KwkY=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=mL41JVU7/zO0p9SYDepF/jseOcbUusSi77B47VsySuySNSCm2kBHtZJI+LCtB7h9ZfDc9q60gPPK6w0f8vmamWooCIAjA7kEE+Smx1NIfuhA03U/jxk9rFnawEkVz4xGEuGTWCnE7aJmoncS9ABqzgAwsC9NVdnDhu2f5hgrnp8= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Sr6duhM1; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="Sr6duhM1" Received: by smtp.kernel.org (Postfix) with ESMTPSA id A659BC19421; Wed, 8 Apr 2026 14:34:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1775658850; bh=MtGTjVVC+mLYgJUWL3jI+tDSobLQGokRrpe7RX8KwkY=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Sr6duhM14+/d0FsYFuIzrL/R4AgbfuBn3udk6cbDqas57kpf8bzvM3JPD4y6dsd2T 7uR7CsNRbsG+gXQjkxTkFQ2VK1uVIY1+fNcCwWpXtXW+AUPIjVlz2ievpGnqpyGrAn n2sV4eht3ru+39CSv8KC6LOtpdIrWoTJiCy6KLrpTlTzPHIQ66ZysJjzDUo4gAUO0l KZw+xomoQ2vZDmI278G54aP4X5HyRG3PsNroYGZsigPKcYQIo7/ifCI9p9Qdi5h0k8 y8XMotObieW32euYp+KdxzXYzoK7Z1HOtZyDDqtibZe3IVp9UtGvamrEk/tgUNxkBs L84SjVc526C4g== From: Tycho Andersen To: Tom Lendacky , John Allen , Herbert Xu , "David S. Miller" , Ashish Kalra Cc: "Borislav Petkov (AMD)" , linux-crypto@vger.kernel.org, linux-kernel@vger.kernel.org, Brijesh Singh , Michael Roth , Alexey Kardashevskiy , Dan Williams , "Tycho Andersen (AMD)" Subject: [PATCH v1 4/4] crypto/ccp: Initialize data during __sev_snp_init_locked() Date: Wed, 8 Apr 2026 08:32:59 -0600 Message-ID: <20260408143259.602767-5-tycho@kernel.org> X-Mailer: git-send-email 2.53.0 In-Reply-To: <20260408143259.602767-1-tycho@kernel.org> References: <20260408143259.602767-1-tycho@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: "Tycho Andersen (AMD)" Sashiko notes: > is the stack variable data left uninitialized when taking the else branch? > Since data.tio_en is later evaluated unconditionally, could stack garbage > cause it to evaluate to true, leading to erroneous attempts to allocate > pages and initialize SEV-TIO on unsupported hardware? If the firmware is too old to support SEV_INIT_EX, data is left uninitialized but used in the debug logging about whether TIO is enabled or not. Fixes: 4be423572da1 ("crypto/ccp: Implement SEV-TIO PCIe IDE (phase1)") Reported-by: Sashiko Assisted-by: Gemini:gemini-3.1-pro-preview Link: https://sashiko.dev/#/patchset/20260324161301.1353976-1-tycho%40kerne= l.org Signed-off-by: Tycho Andersen (AMD) Reviewed-by: Tom Lendacky --- drivers/crypto/ccp/sev-dev.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/crypto/ccp/sev-dev.c b/drivers/crypto/ccp/sev-dev.c index 11e2c667c0ad..7b8c1b44f2da 100644 --- a/drivers/crypto/ccp/sev-dev.c +++ b/drivers/crypto/ccp/sev-dev.c @@ -1356,7 +1356,7 @@ static int __sev_snp_init_locked(int *error, unsigned= int max_snp_asid) { struct sev_data_range_list *snp_range_list __free(kfree) =3D NULL; struct psp_device *psp =3D psp_master; - struct sev_data_snp_init_ex data; + struct sev_data_snp_init_ex data =3D {}; struct sev_device *sev; void *arg =3D &data; int cmd, rc =3D 0; @@ -1420,8 +1420,6 @@ static int __sev_snp_init_locked(int *error, unsigned= int max_snp_asid) */ snp_add_hv_fixed_pages(sev, snp_range_list); =20 - memset(&data, 0, sizeof(data)); - if (max_snp_asid) { data.ciphertext_hiding_en =3D 1; data.max_snp_asid =3D max_snp_asid; --=20 2.53.0