Re: [PATCH v5 1/1] s390/zcrypt: Improve zcrypt reply message verification checks

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [Medium] Uninitialized memory usage and buffer reuse leading to kernel heap information leak
--

--- Patch [1]: [PATCH v5 1/1] s390/zcrypt: Improve zcrypt reply message verification checks ---
commit 52b1c279b5cba2ecec495171bd1e75b2e86fc109
Author: Harald Freudenberger <freude@linux.ibm.com>

s390/zcrypt: Improve zcrypt reply message verification checks

This commit improves reply message verification checks for CCA and EP11
messages in the zcrypt device driver. It updates length field checking to use
size_t and ensures bounds checking before using values to invoke memcpy.

Cc: stable@vger.kernel.org

> diff --git a/drivers/s390/crypto/zcrypt_msgtype6.c b/drivers/s390/crypto/zcrypt_msgtype6.c
> index 40f72cdf284d3..8252fd1856638 100644
> --- a/drivers/s390/crypto/zcrypt_msgtype6.c
> +++ b/drivers/s390/crypto/zcrypt_msgtype6.c
> @@ -853,7 +860,7 @@ 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)
> @@ -863,7 +870,8 @@ static void zcrypt_msgtype6_receive(struct ap_queue *aq,
>  	    t86r->cprbx.cprb_ver_id == 0x02) {

[Severity: Medium]
This is a pre-existing issue, but is it possible for a short reply to cause
an out-of-bounds read here? The cprb_ver_id field is accessed before verifying
that reply->len is large enough to contain the CPRBX header.

Additionally, if the hardware returns a response that hits the else branch
in zcrypt_msgtype6_receive():

drivers/s390/crypto/zcrypt_msgtype6.c:zcrypt_msgtype6_receive() {
	...
	} else {
		memcpy(msg->msg, reply->msg, sizeof(error_reply));
		msg->len = sizeof(error_reply);
	}
	...
}

Only 8 bytes (sizeof(error_reply)) are copied, and the rest of msg->msg
remains user-controlled from the original request.

Could a malicious user craft a request via ZSECSENDCPRB embedding specific
values for cprb_ver_id and fmt2.offset2/count2, and if a short response
forces the else branch, bypass verification?

If convert_response_xcrb() reads the mixed buffer, sees TYPE86_RSP_CODE,
and validates cprb_ver_id == 0x02 from the user's data, it would call
convert_type86_xcrb(), which then copies arbitrary kernel heap memory to
user space using the user-controlled offsets:

drivers/s390/crypto/zcrypt_msgtype6.c:convert_type86_xcrb() {
	...
		if (z_copy_to_user(userspace, xcrb->reply_data_addr,
				   data + msg->fmt2.offset2, msg->fmt2.count2))
			return -EFAULT;
	...
}

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