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

[Harald Freudenberger <freude@linux.ibm.com>]

On 2026-07-29 16:59, sashiko-bot@kernel.org wrote:
> 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()?

And these both are fixed with the next patch in the series !!!