From: sashiko-bot@kernel.org
To: "Harald Freudenberger" <freude@linux.ibm.com>
Cc: "Heiko Carstens" <hca@linux.ibm.com>,
linux-s390@vger.kernel.org, "Vasily Gorbik" <gor@linux.ibm.com>,
"Alexander Gordeev" <agordeev@linux.ibm.com>
Subject: Re: [PATCH v8 1/5] s390/zcrypt: Fix CPRB memory allocation in zcrypt misc code
Date: Wed, 29 Jul 2026 14:52:51 +0000 [thread overview]
Message-ID: <20260729145251.92AC01F00A3A@smtp.kernel.org> (raw)
In-Reply-To: <20260729143928.191969-2-freude@linux.ibm.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Incomplete memory scrubbing in `free_cprbmem()` due to missing 4-byte alignment rounding.
--
--- Patch [1]: [PATCH v8 1/5] s390/zcrypt: Fix CPRB memory allocation in zcrypt misc code ---
commit 8719946bc97657e1ca3c996d1d00474456aa0ef0
Author: Harald Freudenberger <freude@linux.ibm.com>
s390/zcrypt: Fix CPRB memory allocation in zcrypt misc code
Both CPRB alloc functions in zcrypt_ccamisc.c and zcrypt_ep11misc.c
did not round up the memory allocation to a multiple of 4 bytes as it
is needed by the zcrypt layer to process the CPRBs.
Now the alloc_and_prep_cprbmem() and alloc_cprbmem() functions
guarantee that the base CPRB struct and a possible parameter block are
aligned to a 4-byte boundary and the backing memory allocation is
rounded up to the next multiple of 4 byte. Also the free_cprbmem() is
updated and scrubs the rounded up amount of memory.
> diff --git a/drivers/s390/crypto/zcrypt_ep11misc.c b/drivers/s390/crypto/zcrypt_ep11misc.c
> index 3dda9589f2b95..e604c100ccce2 100644
> --- a/drivers/s390/crypto/zcrypt_ep11misc.c
> +++ b/drivers/s390/crypto/zcrypt_ep11misc.c
> @@ -355,21 +356,24 @@ EXPORT_SYMBOL(ep11_check_aes_key);
>
> /*
> * Allocate and prepare ep11 cprb plus additional payload.
> + * It is guaranteed that the memory is aligned to a 4 byte boundary.
> + * Furthermore the memory allocation is rounded up to the next
> + * multiple of 4 bytes (with taking the payload_len into account).
> */
> static void *alloc_cprbmem(size_t payload_len, u32 xflags)
> {
> - size_t len = sizeof(struct ep11_cprb) + payload_len;
> + size_t memlen = ALIGN(sizeof(struct ep11_cprb) + payload_len, 4);
[Severity: Medium]
The commit message states that free_cprbmem() is updated to scrub the rounded
up amount of memory. While this change is present for zcrypt_ccamisc.c, was it
missed for zcrypt_ep11misc.c?
Since alloc_cprbmem() now allocates the rounded up memory size, does
free_cprbmem() in zcrypt_ep11misc.c also need to be updated to scrub the
matching size?
Currently, it still uses the exact unrounded size:
static void free_cprbmem(void *mem, size_t payload_len, bool scrub, u32 xflags)
{
if (mem && scrub)
memzero_explicit(mem, sizeof(struct ep11_cprb) + payload_len);
Could this leave up to 3 bytes of the newly added padding unscrubbed when an
EP11 CPRB is freed? If the cryptographic hardware writes sensitive data into
the padding bytes of a 4-byte aligned response, this data would not be zeroed
before the memory is returned to the allocator.
[ ... ]
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260729143928.191969-1-freude@linux.ibm.com?part=1
next prev parent reply other threads:[~2026-07-29 14:52 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-29 14:39 [PATCH v8 0/5] Improve code in zcrypt msg type 6 handling Harald Freudenberger
2026-07-29 14:39 ` [PATCH v8 1/5] s390/zcrypt: Fix CPRB memory allocation in zcrypt misc code Harald Freudenberger
2026-07-29 14:52 ` sashiko-bot [this message]
2026-07-29 15:10 ` Harald Freudenberger
2026-07-29 14:39 ` [PATCH v8 2/5] s390/zcrypt: Improve CCA CPRB length and overflow checks Harald Freudenberger
2026-07-29 14:59 ` sashiko-bot
2026-07-29 15:11 ` Harald Freudenberger
2026-07-29 14:39 ` [PATCH v8 3/5] s390/zcrypt: Improve EP11 " Harald Freudenberger
2026-07-29 14:52 ` sashiko-bot
2026-07-29 14:39 ` [PATCH v8 4/5] s390/zcrypt: Improve EP11 CPRB domain handling with ASN.1 parsing Harald Freudenberger
2026-07-29 14:50 ` sashiko-bot
2026-07-29 15:25 ` Harald Freudenberger
2026-07-29 14:39 ` [PATCH v8 5/5] s390/zcrypt: Pad trailing CCA or EP11 message with zeros Harald Freudenberger
2026-07-29 15:00 ` sashiko-bot
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=20260729145251.92AC01F00A3A@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=agordeev@linux.ibm.com \
--cc=freude@linux.ibm.com \
--cc=gor@linux.ibm.com \
--cc=hca@linux.ibm.com \
--cc=linux-s390@vger.kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.