Re: [PATCH v4 3/3] s390/crypto: Fix use of mutex in atomic context
Harald Freudenberger <[email protected]>
| Newsgroups | org.kernel.vger.linux-s390,dev.linux.lists.sashiko-reviews |
|---|---|
| Message-ID | <[email protected]> |
On 2026-08-14 14:46, [email protected] wrote: > 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? This is addressed in another patch series for paes_s390.c