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

[sashiko-bot@kernel.org]

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

Pre-existing issues:
- [High] The patch addresses integer overflow and uninitialized memory read vulnerabilities in the CCA CPRB processing function (`xcrb_msg_to_type6cprb_msgx`), but completely overlooks the sibling function `xcrb_msg_to_type6_ep11cprb_msgx` which suffers from identical flaws.
--

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

s390/zcrypt: Improve CCA CPRB length and overflow checks

The xcrb_msg_to_type6cprb_msgx() function lacks proper input
validation, creating security vulnerabilities:
1. Integer overflow after CEIL4 alignment: Signed int variables could
   overflow during 4-byte boundary alignment, causing undersized
   buffer allocations or incorrect bounds checking.
2. Missing minimum size validation: The CPRBX structure is copied from
   userspace without verifying sufficient buffer length. Undersized
   buffers cause uninitialized memory access when reading structure
   fields like cprbx.cprb_len and cprbx.domain.
3. Arithmetic overflow in sum calculations: Adding control block and
   data block sizes could overflow, bypassing size checks and enabling
   buffer overflows.

Fix by using size_t for length calculations, adding U32_MAX boundary
checks after alignment, validating minimum control block size before
copying from userspace, and detecting sum calculation 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 the sibling function
xcrb_msg_to_type6_ep11cprb_msgx() in this same file appears to suffer from
the exact same vulnerabilities being fixed here.

For example, when req_len is smaller than the required struct size,
z_copy_from_user() can complete successfully but leave trailing buffer
bytes uninitialized:

drivers/s390/crypto/zcrypt_msgtype6.c:xcrb_msg_to_type6_ep11cprb_msgx() {
...
	if (z_copy_from_user(userspace, msg->userdata,
			     (char __force __user *)xcrb->req, xcrb->req_len)) {
		return -EFAULT;
	}

	if ((msg->pld_lenfmt & 0x80) == 0x80) { /*ext.len.fmt 2 or 3*/
...
}

Because ap_msg->msg is allocated without zeroing, this reads uninitialized
kernel heap memory to perform routing and access control logic (like
domain, fcode, and whether the request requires admin or usage permission).
Additionally, CEIL4 can overflow for lengths near U64_MAX, bypassing
initial length checks.

Should xcrb_msg_to_type6_ep11cprb_msgx() also receive similar minimum
size validation and overflow checks?

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