Re: [PATCH v4 3/3] s390/crypto: Fix use of mutex in atomic context

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

Pre-existing issues:
- [High] The patch completely misses the exact same preexisting invalid mutex usage in atomic context in the Protected AES (PAES) CTR implementation (`paes_s390.c`).
--

--- Patch [3]: [PATCH v4 3/3] s390/crypto: Fix use of mutex in atomic context ---
commit 709721b3784d3a0026753ef3b28100620270373d
Author: Harald Freudenberger <[email protected]>

s390/crypto: Fix use of mutex in atomic context

This commit replaces a mutex with a binary semaphore in the s390 AES CTR
implementation. This prevents unsafe locking when the crypto routines are
called from atomic or interrupt contexts.

> diff --git a/arch/s390/crypto/aes_s390.c b/arch/s390/crypto/aes_s390.c
> index 10561aa687c78..bd9815988c813 100644
> --- a/arch/s390/crypto/aes_s390.c
> +++ b/arch/s390/crypto/aes_s390.c
[ ... ]
> @@ -569,12 +569,13 @@ static int ctr_aes_crypt(struct skcipher_request *req)
>  	u8 buf[AES_BLOCK_SIZE], *ctrptr;
>  	struct skcipher_walk walk;
>  	unsigned int n, nbytes;
> -	int ret, locked;
> +	bool locked;
> +	int ret;
>  
>  	if (unlikely(!sctx->fc))
>  		return fallback_skcipher_crypt(sctx, req, 0);
>  
> -	locked = mutex_trylock(&ctrblk_lock);
> +	locked = down_trylock(&ctrblk_sem) == 0;

[Severity: High]
This is a pre-existing issue, but it appears the exact same pattern exists in
the Protected AES (PAES) CTR implementation which wasn't updated here.

Looking at ctr_paes_do_crypt() in arch/s390/crypto/paes_s390.c:

	locked = mutex_trylock(&ctrblk_lock);

Since the skcipher API can be invoked from atomic or interrupt contexts (like
network softirqs), does the PAES implementation also risk an atomic context
locking violation? Should arch/s390/crypto/paes_s390.c receive a similar
conversion to a binary semaphore?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=3