All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Harald Freudenberger" <freude@linux.ibm.com>
Cc: "Heiko Carstens" <hca@linux.ibm.com>,
	"Vasily Gorbik" <gor@linux.ibm.com>,
	linux-s390@vger.kernel.org,
	"Alexander Gordeev" <agordeev@linux.ibm.com>
Subject: Re: [PATCH v10 4/5] s390/zcrypt: Improve EP11 CPRB domain handling with ASN.1 parsing
Date: Thu, 30 Jul 2026 14:29:12 +0000	[thread overview]
Message-ID: <20260730142912.C6A361F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260730141509.205970-5-freude@linux.ibm.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] An off-by-one error in bounds checking allows a 1-byte out-of-bounds read when parsing the ASN.1 function tag.
--

--- Patch [4]: [PATCH v10 4/5] s390/zcrypt: Improve EP11 CPRB domain handling with ASN.1 parsing ---
commit 195849014f55379e7fe6dcd2f7156dd9744b4047
Author: Harald Freudenberger <freude@linux.ibm.com>

s390/zcrypt: Improve EP11 CPRB domain handling with ASN.1 parsing

This commit replaces struct overlays in EP11 CPRB domain handling with
explicit ASN.1 parsing to improve security and maintainability. It adds
bounds checking and a new helper function for safe integer encoding.

> 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

[ ... ]

> @@ -1239,51 +1261,94 @@ static long zcrypt_msgtype6_send_ep11_cprb(bool userspace, struct zcrypt_queue *

[ ... ]

> +		/* payload tag */
> +		if (pld[offs++] != 0x30)
> +			return -EINVAL;
> +		/* payload length field */
> +		i = asn1_length_decode(pld + offs, pld_len - offs, &u);
> +		if (i < 0)
> +			return -EINVAL;
> +		offs += i;
> +		if (offs > pld_len || u > pld_len - offs)
> +			return -EINVAL;

[Severity: High]
Does this allow a 1-byte out-of-bounds read of the pld buffer if the ASN.1
payload length field uses a multi-byte encoding that exactly consumes the
remaining pld_len bytes?

If offs exactly equals pld_len, the bounds check offs > pld_len will evaluate
to false. If u is 0, u > pld_len - offs becomes 0 > 0, which is also false.

> +		/* function tag */
> +		if (pld[offs++] != 0x04)

The code would then proceed to read pld[offs++], reading one byte past the
end of the pld buffer.

Should this bounds check use >= instead?

if (offs >= pld_len || u > pld_len - offs)

Additionally, looking at xcrb_msg_to_type6_ep11cprb_msgx() in the same file:

	/* payload length field */
	i = asn1_length_decode(pld + offs, pld_len - offs, &u);
	if (i < 0)
		return -EINVAL;
	offs += i;
	if (offs > pld_len || u > pld_len - offs)
		return -EINVAL;
	/* function tag */
	if (pld[offs++] != 0x04)

This is a pre-existing issue, but does it suffer from the identical bounds
checking flaw?

> +			return -EINVAL;

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260730141509.205970-1-freude@linux.ibm.com?part=4

  reply	other threads:[~2026-07-30 14:29 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-30 14:15 [PATCH v10 0/5] Improve code in zcrypt msg type 6 handling Harald Freudenberger
2026-07-30 14:15 ` [PATCH v10 1/5] s390/zcrypt: Fix CPRB memory allocation in zcrypt misc code Harald Freudenberger
2026-07-30 14:25   ` sashiko-bot
2026-07-30 14:15 ` [PATCH v10 2/5] s390/zcrypt: Improve CCA CPRB length and overflow checks Harald Freudenberger
2026-07-30 14:48   ` sashiko-bot
2026-07-30 14:15 ` [PATCH v10 3/5] s390/zcrypt: Improve EP11 " Harald Freudenberger
2026-07-30 14:35   ` sashiko-bot
2026-07-30 14:15 ` [PATCH v10 4/5] s390/zcrypt: Improve EP11 CPRB domain handling with ASN.1 parsing Harald Freudenberger
2026-07-30 14:29   ` sashiko-bot [this message]
2026-07-30 14:43     ` Harald Freudenberger
2026-07-30 14:15 ` [PATCH v10 5/5] s390/zcrypt: Pad trailing CCA or EP11 message with zeros Harald Freudenberger
2026-07-30 14:29   ` 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=20260730142912.C6A361F000E9@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.