Re: [PATCH v4 1/1] s390/zcrypt: Fix and 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:
- [High] Strict length checks placed before error checks in convert_response_ica and convert_response_ep11_xcrb break retry logic for short error replies.
--

commit 8039067e4a9fd6e25e23de18df187889de05156f
Author: Harald Freudenberger <freude@linux.ibm.com>

s390/zcrypt: Fix and improve zcrypt reply message verification checks

This commit improves boundary checks and reply size validations in the
zcrypt device driver to prevent out-of-bounds memory accesses. Length
validations are added before processing reply structures for CCA, EP11,
and ICA messages.

Cc: stable@vger.kernel.org

> diff --git a/drivers/s390/crypto/zcrypt_msgtype6.c b/drivers/s390/crypto/zcrypt_msgtype6.c
> index 3df1d676de5d8..9bd08f0376c33 100644
> --- a/drivers/s390/crypto/zcrypt_msgtype6.c
> +++ b/drivers/s390/crypto/zcrypt_msgtype6.c
[ ... ]
> @@ -777,11 +786,15 @@ static int convert_response_ica(struct zcrypt_queue *zq,
>  {
>  	struct type86x_reply *msg = reply->msg;
>  
> +	/* reply->len is always >= sizeof(struct error_hdr) here */
> +
>  	switch (msg->hdr.type) {
>  	case TYPE82_RSP_CODE:
>  	case TYPE88_RSP_CODE:
>  		return convert_error(zq, reply);
>  	case TYPE86_RSP_CODE:
> +		if (reply->len < sizeof(struct type86x_reply))
> +			return -EINVAL;

[Severity: High]
Does this length check preempt the error handling for short hardware error
replies? 

If the hardware returns a short TYPE86 error reply (such as format 1 TYPE86
errors which are only 8 bytes), it appears this will immediately return
-EINVAL before the msg->hdr.reply_code check can process it.

This bypasses the error conversion and retry logic in convert_error() for
transient hardware or bus errors (e.g., REP82_ERROR_TRANSPORT_FAIL), causing
them to falsely propagate as invalid arguments to userspace applications
instead of being retried.

>  		if (msg->cprbx.ccp_rtcode &&
>  		    msg->cprbx.ccp_rscode == 0x14f &&
>  		    outputdatalength > 256) {
[ ... ]
> @@ -854,11 +876,15 @@ static int convert_response_ep11_xcrb(bool userspace, struct zcrypt_queue *zq,
>  {
>  	struct type86_ep11_reply *msg = reply->msg;
>  
> +	/* reply->len is always >= sizeof(struct error_hdr) here */
> +
>  	switch (msg->hdr.type) {
>  	case TYPE82_RSP_CODE:
>  	case TYPE87_RSP_CODE:
>  		return convert_error(zq, reply);
>  	case TYPE86_RSP_CODE:
> +		if (reply->len < sizeof(struct type86_ep11_reply))
> +			return -EINVAL;

[Severity: High]
Similarly, does this strict length check break the error processing and retry
mechanism for EP11 requests if a short TYPE86 error reply is returned?

>  		if (msg->hdr.reply_code)
>  			return convert_error(zq, reply);
>  		if (msg->cprbx.cprb_ver_id == 0x04)

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