All of lore.kernel.org
 help / color / mirror / Atom feed
From: Finn Callies <fcallies@linux.ibm.com>
To: Harald Freudenberger <freude@linux.ibm.com>,
	dengler@linux.ibm.com, ifranzki@linux.ibm.com
Cc: linux-s390@vger.kernel.org, Heiko Carstens <hca@linux.ibm.com>,
	Vasily Gorbik <gor@linux.ibm.com>,
	Alexander Gordeev <agordeev@linux.ibm.com>
Subject: Re: [PATCH v6 1/1] s390/zcrypt: Improve zcrypt reply message verification checks
Date: Thu, 6 Aug 2026 07:22:42 +0200	[thread overview]
Message-ID: <bbd320da-c0fc-4fdd-8e19-e4dd4d7b6e41@linux.ibm.com> (raw)
In-Reply-To: <20260804144926.241039-2-freude@linux.ibm.com>



On 04.08.26 16:49, Harald Freudenberger wrote:
> 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.
> 
> Signed-off-by: Harald Freudenberger <freude@linux.ibm.com>
> ---
>   drivers/s390/crypto/zcrypt_msgtype50.c |  39 ++++---
>   drivers/s390/crypto/zcrypt_msgtype6.c  | 151 ++++++++++++++++---------
>   2 files changed, 126 insertions(+), 64 deletions(-)
> 
> diff --git a/drivers/s390/crypto/zcrypt_msgtype50.c b/drivers/s390/crypto/zcrypt_msgtype50.c
> index d6fc2d8e7fad..ef925b399806 100644
> --- a/drivers/s390/crypto/zcrypt_msgtype50.c
> +++ b/drivers/s390/crypto/zcrypt_msgtype50.c
> @@ -416,26 +416,39 @@ static void zcrypt_msgtype50_receive(struct ap_queue *aq,
>   		.reply_code = REP82_ERROR_MACHINE_FAILURE,
>   	};
>   	struct type80_hdr *t80h;
> -	int len;
> +	size_t len;
>   
>   	/* Copy the reply message to the request message buffer. */
>   	if (!reply)
>   		goto out;	/* ap_msg->rc indicates the error */
> +
>   	t80h = reply->msg;
> -	if (t80h->type == TYPE80_RSP_CODE) {
> -		len = t80h->len;
> -		if (len > reply->bufsize || len > msg->bufsize ||
> -		    len != reply->len) {
> -			pr_debug("len mismatch => EMSGSIZE\n");

I don't like this debug statement, its very undescriptive. What is len? 
What does it mismatch against? What does the mismatch mean?

The "=> EMSGSIZE" looks very uncommon for me as well, is this a common 
way of logging error paths?

> -			msg->rc = -EMSGSIZE;
> -			goto out;
> -		}
> -		memcpy(msg->msg, reply->msg, len);
> -		msg->len = len;
> -	} else {
> -		memcpy(msg->msg, reply->msg, sizeof(error_reply));
> +
> +	if (t80h->type != TYPE80_RSP_CODE) {
> +		if (reply->len < sizeof(error_reply))
> +			memcpy(msg->msg, &error_reply, sizeof(error_reply));
> +		else
> +			memcpy(msg->msg, reply->msg, sizeof(error_reply));
>   		msg->len = sizeof(error_reply);
> +		goto out;
> +	}
> +
> +	len = t80h->len;
> +	if (len != reply->len) {
> +		pr_warn_ratelimited("len %zu rpl.len %zu mismatch => EMSGSIZE\n",
> +				    len, reply->len);

Same here. What is len? rpl.len is a technical statement, but logs 
should be descriptive right?

> +		msg->rc = -EMSGSIZE;
> +		goto out;
>   	}
> +	if (len > reply->bufsize || len > msg->bufsize) {
> +		pr_warn_ratelimited("len %zu exceeds buf %zu/%zu => EMSGSIZE\n",
> +				    len, reply->bufsize, msg->bufsize);

Why buf instead of buffer? Why safe space here?

> +		msg->rc = -EMSGSIZE;
> +		goto out;
> +	}
> +	memcpy(msg->msg, reply->msg, len);
> +	msg->len = len;
> +
>   out:
>   	complete(&msg->response.work);
>   }
> diff --git a/drivers/s390/crypto/zcrypt_msgtype6.c b/drivers/s390/crypto/zcrypt_msgtype6.c
> index 3df1d676de5d..b98449913e24 100644
> --- a/drivers/s390/crypto/zcrypt_msgtype6.c
> +++ b/drivers/s390/crypto/zcrypt_msgtype6.c
> @@ -766,6 +766,13 @@ static int convert_type86_rng(struct zcrypt_queue *zq,
>   
>   	if (msg->cprbx.ccp_rtcode != 0 || msg->cprbx.ccp_rscode != 0)
>   		return -EINVAL;
> +	/*
> +	 * Note that offset2 and count2 have already been checked in
> +	 * zcrypt_msgtype6_receive(). So only check for not exceeding
> +	 * the hard coded rng buffer size.
> +	 */
> +	if (msg->fmt2.count2 > ZCRYPT_RNG_BUFFER_SIZE)
> +		return -EMSGSIZE;
>   	memcpy(buffer, data + msg->fmt2.offset2, msg->fmt2.count2);
>   	return msg->fmt2.count2;
>   }
> @@ -928,48 +935,75 @@ static void zcrypt_msgtype6_receive(struct ap_queue *aq,
>   	};
>   	struct ap_response_type *resp_type = &msg->response;
>   	struct type86x_reply *t86r;
> -	int len;
> +	size_t len, len1, len2 = 0;
>   
>   	/* Copy the reply message to the request message buffer. */
>   	if (!reply)
>   		goto out;	/* ap_msg->rc indicates the error */
> +
>   	t86r = reply->msg;
> -	if (t86r->hdr.type == TYPE86_RSP_CODE &&
> -	    t86r->cprbx.cprb_ver_id == 0x02) {
> -		switch (resp_type->type) {
> -		case CEXXC_RESPONSE_TYPE_ICA:
> -			len = sizeof(struct type86x_reply) + t86r->length;
> -			if (len > reply->bufsize || len > msg->bufsize ||
> -			    len != reply->len) {
> -				pr_debug("len mismatch => EMSGSIZE\n");
> -				msg->rc = -EMSGSIZE;
> -				goto out;
> -			}
> -			memcpy(msg->msg, reply->msg, len);
> -			msg->len = len;
> -			break;
> -		case CEXXC_RESPONSE_TYPE_XCRB:
> -			if (t86r->fmt2.count2)
> -				len = t86r->fmt2.offset2 + t86r->fmt2.count2;
> -			else
> -				len = t86r->fmt2.offset1 + t86r->fmt2.count1;
> -			if (len > reply->bufsize || len > msg->bufsize ||
> -			    len != reply->len) {
> -				pr_debug("len mismatch => EMSGSIZE\n");
> +
> +	if (t86r->hdr.type != TYPE86_RSP_CODE ||
> +	    t86r->cprbx.cprb_ver_id != 0x02) {
> +		if (reply->len < sizeof(error_reply))
> +			memcpy(msg->msg, &error_reply, sizeof(error_reply));
> +		else
> +			memcpy(msg->msg, reply->msg, sizeof(error_reply));
> +		msg->len = sizeof(error_reply);
> +		goto out;
> +	}
> +
> +	switch (resp_type->type) {
> +	case CEXXC_RESPONSE_TYPE_ICA:
> +		len = sizeof(struct type86x_reply) + (size_t)t86r->length;
> +		break;
> +	case CEXXC_RESPONSE_TYPE_XCRB:
> +		len1 = (size_t)t86r->fmt2.offset1 + (size_t)t86r->fmt2.count1;
> +		if (t86r->fmt2.offset1 > reply->len ||
> +		    t86r->fmt2.count1 > reply->len) {
> +			pr_warn_ratelimited(
> +				"offset1 %u count1 %u rpl.len %zu mismatch => EMSGSIZE\n",
> +				t86r->fmt2.offset1, t86r->fmt2.count1,
> +				reply->len);

same here

> +			msg->rc = -EMSGSIZE;
> +			goto out;
> +		}
> +		if (t86r->fmt2.count2) {
> +			len2 = (size_t)t86r->fmt2.offset2 +
> +				(size_t)t86r->fmt2.count2;
> +			if (t86r->fmt2.offset2 > reply->len ||
> +			    t86r->fmt2.count2 > reply->len) {
> +				pr_warn_ratelimited(
> +					"offset2 %u count2 %u rpl.len %zu mismatch => EMSGSIZE\n",
> +					t86r->fmt2.offset2, t86r->fmt2.count2,
> +					reply->len);

same here

>   				msg->rc = -EMSGSIZE;
>   				goto out;
>   			}
> -			memcpy(msg->msg, reply->msg, len);
> -			msg->len = len;
> -			break;
> -		default:
> -			memcpy(msg->msg, &error_reply, sizeof(error_reply));
> -			msg->len = sizeof(error_reply);
>   		}
> -	} else {
> -		memcpy(msg->msg, reply->msg, sizeof(error_reply));
> +		len = max_t(size_t, len1, len2);
> +		break;
> +	default:
> +		memcpy(msg->msg, &error_reply, sizeof(error_reply));
>   		msg->len = sizeof(error_reply);
> +		goto out;
> +	}
> +
> +	if (len != reply->len) {
> +		pr_warn_ratelimited("len %zu rpl.len %zu mismatch => EMSGSIZE\n",
> +				    len, reply->len);

same here

> +		msg->rc = -EMSGSIZE;
> +		goto out;
>   	}
> +	if (len > reply->bufsize || len > msg->bufsize) {
> +		pr_warn_ratelimited("len %zu exceeds buf %zu/%zu => EMSGSIZE\n",
> +				    len, reply->bufsize, msg->bufsize);

same here

> +		msg->rc = -EMSGSIZE;
> +		goto out;
> +	}
> +	memcpy(msg->msg, reply->msg, len);
> +	msg->len = len;
> +
>   out:
>   	complete(&resp_type->work);
>   }
> @@ -992,34 +1026,49 @@ static void zcrypt_msgtype6_receive_ep11(struct ap_queue *aq,
>   	};
>   	struct ap_response_type *resp_type = &msg->response;
>   	struct type86_ep11_reply *t86r;
> -	int len;
> +	size_t len;
>   
>   	/* Copy the reply message to the request message buffer. */
>   	if (!reply)
>   		goto out;	/* ap_msg->rc indicates the error */
> +
>   	t86r = reply->msg;
> -	if (t86r->hdr.type == TYPE86_RSP_CODE &&
> -	    t86r->cprbx.cprb_ver_id == 0x04) {
> -		switch (resp_type->type) {
> -		case CEXXC_RESPONSE_TYPE_EP11:
> -			len = t86r->fmt2.offset1 + t86r->fmt2.count1;
> -			if (len > reply->bufsize || len > msg->bufsize ||
> -			    len != reply->len) {
> -				pr_debug("len mismatch => EMSGSIZE\n");
> -				msg->rc = -EMSGSIZE;
> -				goto out;
> -			}
> -			memcpy(msg->msg, reply->msg, len);
> -			msg->len = len;
> -			break;
> -		default:
> +
> +	if (t86r->hdr.type != TYPE86_RSP_CODE ||
> +	    t86r->cprbx.cprb_ver_id != 0x04) {
> +		if (reply->len < sizeof(error_reply))
>   			memcpy(msg->msg, &error_reply, sizeof(error_reply));
> -			msg->len = sizeof(error_reply);
> -		}
> -	} else {
> -		memcpy(msg->msg, reply->msg, sizeof(error_reply));
> +		else
> +			memcpy(msg->msg, reply->msg, sizeof(error_reply));
>   		msg->len = sizeof(error_reply);
> +		goto out;
>   	}
> +
> +	switch (resp_type->type) {
> +	case CEXXC_RESPONSE_TYPE_EP11:
> +		len = t86r->fmt2.offset1 + (size_t)t86r->fmt2.count1;
> +		break;
> +	default:
> +		memcpy(msg->msg, &error_reply, sizeof(error_reply));
> +		msg->len = sizeof(error_reply);
> +		goto out;
> +	}
> +
> +	if (len != reply->len) {
> +		pr_warn_ratelimited("len %zu rpl.len %zu mismatch => EMSGSIZE\n",
> +				    len, reply->len);

same here

> +		msg->rc = -EMSGSIZE;
> +		goto out;
> +	}
> +	if (len > reply->bufsize || len > msg->bufsize) {
> +		pr_warn_ratelimited("len %zu exceeds buf %zu/%zu => EMSGSIZE\n",
> +				    len, reply->bufsize, msg->bufsize);

same here

> +		msg->rc = -EMSGSIZE;
> +		goto out;
> +	}
> +	memcpy(msg->msg, reply->msg, len);
> +	msg->len = len;
> +
>   out:
>   	complete(&resp_type->work);
>   }


  parent reply	other threads:[~2026-08-06  5:22 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-04 14:49 [PATCH v6 0/1] Improve zcrypt reply message verification checks Harald Freudenberger
2026-08-04 14:49 ` [PATCH v6 1/1] s390/zcrypt: " Harald Freudenberger
2026-08-04 15:25   ` sashiko-bot
2026-08-06  5:22   ` Finn Callies [this message]
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=bbd320da-c0fc-4fdd-8e19-e4dd4d7b6e41@linux.ibm.com \
    --to=fcallies@linux.ibm.com \
    --cc=agordeev@linux.ibm.com \
    --cc=dengler@linux.ibm.com \
    --cc=freude@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.