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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.