Re: [PATCH v7 2/9] s390/crypto: Fix missing scrub of temp buffers with PAES algorithm

[sashiko-bot@kernel.org]

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

Pre-existing issues:
- [Medium] Incomplete Fix / Data Exposure: The patch fixes a missing scrub of the `buf` temporary buffer in `ctr_paes_do_crypt()` to prevent data exposure, but misses the exact same vulnerability in `ctr_aes_crypt()` within `arch/s390/crypto/aes_s390.c`.
--

commit 40d179d4c1cbb2f9d3b0a3104c9a0096f37f307f
Author: Harald Freudenberger <freude@linux.ibm.com>

s390/crypto: Fix missing scrub of temp buffers with PAES algorithm

This commit addresses a missing scrub of temporary buffers in the PAES crypto 
algorithm. It zeroes out the processing buffer in ctr_paes_do_crypt() and 
ensures the entire parameter block is scrubbed in __xts_2keys_prep_param() to 
avoid exposing sensitive data.

> diff --git a/arch/s390/crypto/paes_s390.c b/arch/s390/crypto/paes_s390.c
> index ccc7da106c3a0..d075b0241f1f5 100644
> --- a/arch/s390/crypto/paes_s390.c
> +++ b/arch/s390/crypto/paes_s390.c
> @@ -1044,6 +1044,7 @@ static int ctr_paes_do_crypt(struct s390_paes_ctx *ctx,
>  	}
>  
>  out:
> +	memzero_explicit(buf, sizeof(buf));
>  	pr_debug("rc=%d\n", rc);
>  	return rc;
>  }

[Severity: Medium]
This isn't a bug introduced by this patch, but while fixing the missing scrub
for PAES here, does the exact same vulnerability exist for standard AES in
arch/s390/crypto/aes_s390.c?

Looking at ctr_aes_crypt() in that file, it similarly uses a local stack 
buffer buf to process partial CTR blocks:

arch/s390/crypto/aes_s390.c:ctr_aes_crypt() {
        ...
        u8 buf[AES_BLOCK_SIZE], *ctrptr;
        ...
        if (nbytes) {
                memset(buf, 0, AES_BLOCK_SIZE);
                memcpy(buf, walk.src.virt.addr, nbytes);
                cpacf_kmctr(sctx->fc, sctx->key, buf, buf,
                            AES_BLOCK_SIZE, walk.iv);
                memcpy(walk.dst.virt.addr, buf, nbytes);
                ...
        }

        return ret;
}

This buffer holds sensitive payload data but returns without being scrubbed via
memzero_explicit(). Could this leave cryptographic data on the kernel stack
where it could be exposed if stack memory is later leaked? Should this same fix
be applied to standard AES as well?

[ ... ]

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