From: Harald Freudenberger <freude@linux.ibm.com>
To: dengler@linux.ibm.com, fcallies@linux.ibm.com, ifranzki@linux.ibm.com
Cc: freude@linux.ibm.com, linux-s390@vger.kernel.org,
Heiko Carstens <hca@linux.ibm.com>,
Vasily Gorbik <gor@linux.ibm.com>,
Alexander Gordeev <agordeev@linux.ibm.com>
Subject: [PATCH v9 0/5] Improve code in zcrypt msg type 6 handling
Date: Wed, 29 Jul 2026 17:44:53 +0200 [thread overview]
Message-ID: <20260729154458.195135-1-freude@linux.ibm.com> (raw)
Rework the limit and overflow checks in the both functions
xcrb_msg_to_type6_ep11cprb_msgx() and xcrb_msg_to_type6cprb_msgx().
And more ... all related to the length checks done in these both
functions.
Changelog:
v1: initial version, one patch dealing with overflow checks around
the use of the CEIL4 macro in zcrypt_msgtype6.c
v2: Sashiko found a regression: The check
if (ap_msg->len > ap_msg->bufsize)
was missing in the rework. Added again this important check.
v3: - Split into two patches - one for CCA one for EP11
- rework upper limit/overflow check
- add lower limit check
v4: - tried to address all the remaining complains from sashiko.
v5: - Yea, sashiko still found out that the min req size needs
to take the minimal payload header into account. Fixed.
v6: - And finally add padding zeros when there is a gap between
user space provided message size and rounded message size
in kernel.
v7: - As requested by Holger, the padding code is now an own patch.
- As the length checks are now so strict the allocation in the
both misc files needed adaption to correctly allocate 4 byte
rounded up message buffers.
- The EP11 length check has been found to be a mess. The payload
is asn1 encoded and now the length parses parts of this payload
to extract the needed fields (function value).
- Furthermore another function zcrypt_msgtype6_send_ep11_cprb()
also needed to be adjusted to parse the asn1 payload to patch
the domain value into the payload.
v8: - Sashiko found out that the cprb free with memory scrub also
needs adaption when the allocation rounds up to a 4 byte
boundary. So fixed just this in the first patch of the series.
v9: - hunk for cprb free with 4 byte boundary for EP11 was missing.
- use of put_unaligned_be16/32 instead of direct cast and store.
Harald Freudenberger (5):
s390/zcrypt: Fix CPRB memory allocation in zcrypt misc code
s390/zcrypt: Improve CCA CPRB length and overflow checks
s390/zcrypt: Improve EP11 CPRB length and overflow checks
s390/zcrypt: Improve EP11 CPRB domain handling with ASN.1 parsing
s390/zcrypt: Pad trailing CCA or EP11 message with zeros
drivers/s390/crypto/zcrypt_ccamisc.c | 20 +-
drivers/s390/crypto/zcrypt_ep11misc.c | 16 +-
drivers/s390/crypto/zcrypt_msgtype6.c | 358 ++++++++++++++++++--------
3 files changed, 271 insertions(+), 123 deletions(-)
--
2.43.0
next reply other threads:[~2026-07-29 15:45 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-29 15:44 Harald Freudenberger [this message]
2026-07-29 15:44 ` [PATCH v9 1/5] s390/zcrypt: Fix CPRB memory allocation in zcrypt misc code Harald Freudenberger
2026-07-29 16:02 ` sashiko-bot
2026-07-29 15:44 ` [PATCH v9 2/5] s390/zcrypt: Improve CCA CPRB length and overflow checks Harald Freudenberger
2026-07-29 16:19 ` sashiko-bot
2026-07-29 15:44 ` [PATCH v9 3/5] s390/zcrypt: Improve EP11 " Harald Freudenberger
2026-07-29 16:35 ` sashiko-bot
2026-07-29 15:44 ` [PATCH v9 4/5] s390/zcrypt: Improve EP11 CPRB domain handling with ASN.1 parsing Harald Freudenberger
2026-07-29 16:46 ` sashiko-bot
2026-07-29 15:44 ` [PATCH v9 5/5] s390/zcrypt: Pad trailing CCA or EP11 message with zeros Harald Freudenberger
2026-07-29 17:07 ` 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=20260729154458.195135-1-freude@linux.ibm.com \
--to=freude@linux.ibm.com \
--cc=agordeev@linux.ibm.com \
--cc=dengler@linux.ibm.com \
--cc=fcallies@linux.ibm.com \
--cc=gor@linux.ibm.com \
--cc=hca@linux.ibm.com \
--cc=ifranzki@linux.ibm.com \
--cc=linux-s390@vger.kernel.org \
/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.