Re: [PATCH v8 2/5] s390/zcrypt: Improve CCA CPRB length and overflow checks

[sashiko-bot@kernel.org]

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

Pre-existing issues:
- [Critical] An integer overflow in the length calculation of EP11 requests bypasses the AP message buffer bounds check, leading to a massive heap buffer overflow or immediate kernel panic during the `copy_from_user` operation.
- [High] The `xcrb_msg_to_type6_ep11cprb_msgx()` function does not verify that the user-provided `xcrb->req_len` is sufficiently large (e.g., at least `sizeof(struct ep11_cprb)`) before copying from userspace, allowing undersized requests to leave critical message fields populated with uninitialized kernel memory.
--

--- Patch [2]: [PATCH v8 2/5] s390/zcrypt: Improve CCA CPRB length and overflow checks ---
commit 9af37e5b015a5cc6a88563feffcb032b0b3d9669
Author: Harald Freudenberger <freude@linux.ibm.com>

s390/zcrypt: Improve CCA CPRB length and overflow checks

The commit fixes integer overflows and missing length checks in
xcrb_msg_to_type6cprb_msgx() by validating input lengths and checking for
addition overflows.

> diff --git a/drivers/s390/crypto/zcrypt_msgtype6.c b/drivers/s390/crypto/zcrypt_msgtype6.c
> index 40f72cdf284d3..fb37e28c82424 100644
> --- a/drivers/s390/crypto/zcrypt_msgtype6.c
> +++ b/drivers/s390/crypto/zcrypt_msgtype6.c

[ ... ]

> @@ -437,10 +428,13 @@ static int xcrb_msg_to_type6cprb_msgx(bool userspace, struct ap_message *ap_msg,
>  	}
>  
>  	/* copy data block */
> -	if (xcrb->request_data_length &&
> -	    z_copy_from_user(userspace, req_data, xcrb->request_data_address,
> -			     xcrb->request_data_length))
> -		return -EFAULT;
> +	if (xcrb->request_data_length) {
> +		req_data = ap_msg->msg + sizeof(struct type6_hdr) + req_cblen;
> +		if (z_copy_from_user(userspace, req_data,
> +				     xcrb->request_data_address,
> +				     xcrb->request_data_length))
> +			return -EFAULT;
> +	}
>  
>  	return 0;
>  }

[Severity: High]
This isn't a bug introduced by this patch, but looking further down in the
same file, xcrb_msg_to_type6_ep11cprb_msgx() seems to have the same missing
minimum size validation that this patch fixes for CCA CPRB.

In drivers/s390/crypto/zcrypt_msgtype6.c:xcrb_msg_to_type6_ep11cprb_msgx():

	/* Import CPRB data from the ioctl input parameter */
	if (z_copy_from_user(userspace, msg->userdata,
			     (char __force __user *)xcrb->req, xcrb->req_len)) {

If the user-provided xcrb->req_len is smaller than sizeof(struct ep11_cprb),
the rest of the message header could remain uninitialized. Could this result
in uninitialized kernel memory dictating control flow or being used to route
requests?

[Severity: Critical]
This is a pre-existing issue, but xcrb_msg_to_type6_ep11cprb_msgx() also
appears to suffer from the same integer overflow issue:

In drivers/s390/crypto/zcrypt_msgtype6.c:xcrb_msg_to_type6_ep11cprb_msgx():

	/* length checks */
	ap_msg->len = sizeof(struct type6_hdr) + CEIL4(xcrb->req_len);
	if (ap_msg->len > ap_msg->bufsize)
		return -EINVAL;

If a user provides a large 64-bit xcrb->req_len like 0xFFFFFFFFFFFFFFB0,
could CEIL4(xcrb->req_len) wrap around, bypassing the ap_msg->bufsize
check, and resulting in a huge buffer overflow or kernel panic during the
subsequent z_copy_from_user()?

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