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 v6 0/1] Improve zcrypt reply message verification checks
Date: Tue, 4 Aug 2026 16:49:25 +0200 [thread overview]
Message-ID: <20260804144926.241039-1-freude@linux.ibm.com> (raw)
Add or improve checks related to buffer sizes and reply sizes to the
handling of replies from the crypto cards for CCA, EP11 (AP message
type 6) and ICA (AP type 50) messages. The verification code related
to reply field length was not designed well and thus firmware
deficiencies could lead to unexpected behavior in the zcrypt device
driver. Thus improve the code to more closely inspect especially
length fields at message replies.
Rework zcrypt_msgtype6_receive(), zcrypt_msgtype6_receive_ep11() and
zcrypt_msgtype50_receive() to validate reply lengths more carefully
before copying data back into the request buffer. Use size_t for
length calculations, reject inconsistent reply sizes, and add
defensive handling for short invalid replies. For XCRB replies,
validate both reply segments and derive the effective message length
from the covered range instead of trusting only the second segment.
Changelog:
v1 - initial patch
v2 - fixed typo in header check_for_overflow -> check_add_overflow.
v3 - rephrased and smoothed subject and text of the patch. It is now
"s390/zcrypt: Improve zcrypt reply message verification checks"
and the text does not talk about malicious cards any more.
Updated Reviewed-by tags
v4 - As sashiko clearly states the addition of two 32 bit values can
mathematically never overflow a 64 bit value and thus the
check_add_overflow() was total overkill - removed.
v5 - Sashiko had a by-catch related to the very same fields. Under
some circumstances the fields count1 and offset1 of the CPRB
where not checked but used for a memcpy to userspace. So again a
rework of the check of these x86 header fields in the receiving
function before the CPRB is processed to be copied in parts to
userspace. Removed all reviewed-by as I want to have another
developer look onto this patch again.
v6 - Again reworked and re-structured the code. As the very same
pattern appears with message type 50 also reworked the receive
function there.
Harald Freudenberger (1):
s390/zcrypt: Improve zcrypt reply message verification checks
drivers/s390/crypto/zcrypt_msgtype50.c | 39 ++++---
drivers/s390/crypto/zcrypt_msgtype6.c | 151 ++++++++++++++++---------
2 files changed, 126 insertions(+), 64 deletions(-)
--
2.43.0
next reply other threads:[~2026-08-04 14:49 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-04 14:49 Harald Freudenberger [this message]
2026-08-04 14:49 ` [PATCH v6 1/1] s390/zcrypt: Improve zcrypt reply message verification checks Harald Freudenberger
2026-08-04 15:25 ` sashiko-bot
2026-08-06 5:22 ` Finn Callies
2026-08-07 7:39 ` Finn Callies
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=20260804144926.241039-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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox