Re: [PATCH v3 2/2] s390/zcrypt: Improve EP11 CPRB length and overflow checks

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] The patch replaces a working 64-bit integer overflow check with a flawed one, introducing a bypass for 64-bit wrap-arounds in the CEIL4 macro that allows a Denial of Service (DoS) via usercopy hardening.
--

--- Patch [2]: [PATCH v3 2/2] s390/zcrypt: Improve EP11 CPRB length and overflow checks ---
commit b608e764c33b544400d55b5be70e199d907fd586
Author: Harald Freudenberger <freude@linux.ibm.com>

s390/zcrypt: Improve EP11 CPRB length and overflow checks

This commit modifies length and overflow checks for EP11 CPRB requests
and replies. It replaces an existing overflow check with a U32_MAX check
after alignment and adds minimum size validations before copying from
userspace.

> diff --git a/drivers/s390/crypto/zcrypt_msgtype6.c b/drivers/s390/crypto/zcrypt_msgtype6.c
> index 4ac767661cb50..3b56b7745588c 100644
> --- a/drivers/s390/crypto/zcrypt_msgtype6.c
> +++ b/drivers/s390/crypto/zcrypt_msgtype6.c
> @@ -474,16 +474,24 @@ static int xcrb_msg_to_type6_ep11cprb_msgx(bool userspace, struct ap_message *ap
>  		unsigned int	dom_val;	/* domain id	   */
>  	} __packed * payload_hdr = NULL;
>  
> -	if (CEIL4(xcrb->req_len) < xcrb->req_len)
> -		return -EINVAL; /* overflow after alignment*/
> +	size_t req_len, rep_len;
>  
> -	/* length checks */
> -	ap_msg->len = sizeof(struct type6_hdr) + CEIL4(xcrb->req_len);
> +	/* request length and overflow checks */
> +	if (xcrb->req_len < sizeof(struct ep11_cprb) + 2 * sizeof(unsigned char))
> +		return -EINVAL;
> +	req_len = CEIL4(xcrb->req_len);
> +	if (req_len > U32_MAX)
> +		return -EINVAL;

[Severity: High]
Does this new check fail to detect 64-bit wrap-arounds that the old check
correctly caught?

If xcrb->req_len is set to U64_MAX - 1 (0xFFFFFFFFFFFFFFFE), the + 3 inside
the CEIL4 macro wraps around in 64-bit unsigned arithmetic to 1, causing
CEIL4 to evaluate to 0.

Since req_len becomes 0, the req_len > U32_MAX check passes, bypassing the
length validation.

Later in xcrb_msg_to_type6_ep11cprb_msgx(), z_copy_from_user() is called
with this massive, unvalidated xcrb->req_len:

	if (z_copy_from_user(userspace, msg->userdata,
			     (char __force __user *)xcrb->req, xcrb->req_len)) {

Could this large size passed to z_copy_from_user() trigger a WARN_ON_ONCE
in the kernel's usercopy hardening (check_copy_size) because bytes > INT_MAX,
potentially leading to a kernel panic in environments with panic_on_warn
enabled?

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