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 v9 4/5] s390/zcrypt: Improve EP11 CPRB domain handling with ASN.1 parsing
Date: Wed, 29 Jul 2026 16:46:46 +0000 [thread overview]
Message-ID: <20260729164647.60ED81F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260729154458.195135-5-freude@linux.ibm.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Critical] Missing bounds checking before reading `pld[offs++]` causes an integer underflow in `pld_len - offs`, bypassing bounds checks and enabling an Out-Of-Bounds (OOB) read and write.
--
--- Patch [4]: [PATCH v9 4/5] s390/zcrypt: Improve EP11 CPRB domain handling with ASN.1 parsing ---
commit 750aceaeb85ad5fa9ff8e2614110f89a4c147522
Author: Harald Freudenberger <freude@linux.ibm.com>
s390/zcrypt: Improve EP11 CPRB domain handling with ASN.1 parsing
This commit replaces struct overlays with explicit ASN.1 parsing for EP11
CPRB domain handling. It introduces bounds checking at each parsing step
and adds a helper function to safely write integer values.
> diff --git a/drivers/s390/crypto/zcrypt_msgtype6.c b/drivers/s390/crypto/zcrypt_msgtype6.c
> --- a/drivers/s390/crypto/zcrypt_msgtype6.c
> +++ b/drivers/s390/crypto/zcrypt_msgtype6.c
[ ... ]
> @@ -1235,51 +1258,90 @@ static long zcrypt_msgtype6_send_ep11_cprb(bool userspace, struct zcrypt_queue *
> struct ap_message *ap_msg)
> {
[ ... ]
> + /* payload length field */
> + i = asn1_length_decode(pld + offs, pld_len - offs, &u);
> + if (i < 0)
> + return -EINVAL;
> + offs += i;
> + if (u > pld_len - offs)
> + return -EINVAL;
> + /* function tag */
> + if (pld[offs++] != 0x04)
[Severity: Critical]
If the ASN.1 payload tag and length encoding completely consume the payload
buffer, couldn't offs become equal to pld_len here?
If offs equals pld_len, does this array access read out of bounds and
increment offs past pld_len?
If offs exceeds pld_len, it appears the subsequent pld_len - offs
calculations will underflow to SIZE_MAX. Would this bypass the remaining
bounds checks, such as pld_len - offs >= 3, and potentially allow
asn1_int_encode() to write out of bounds?
Additionally, it looks like a similar pattern exists in
xcrb_msg_to_type6_ep11cprb_msgx() where pld[offs++] is checked for the
function tag without a prior bounds check.
> + return -EINVAL;
> + /* function length */
> + i = asn1_length_decode(pld + offs, pld_len - offs, &u);
> + if (i < 0)
> + return -EINVAL;
> + offs += i;
> + if (u > pld_len - offs)
> + return -EINVAL;
[ ... ]
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260729154458.195135-1-freude@linux.ibm.com?part=4
next prev parent reply other threads:[~2026-07-29 16:46 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-29 15:44 [PATCH v9 0/5] Improve code in zcrypt msg type 6 handling Harald Freudenberger
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 [this message]
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=20260729164647.60ED81F000E9@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.