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

[sashiko-bot@kernel.org]

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

Pre-existing issues:
- [High] The standard AES CTR implementation (`ctr-aes-s390`) calls `mutex_trylock()` and `mutex_unlock()` within its encryption routine `ctr_aes_crypt()`. This is unsafe because synchronous skcipher algorithms can be invoked from atomic/interrupt contexts (such as softirqs processing IPsec traffic), leading to locking violations and potential crashes.
--

commit 54e6d65629d9606907edef94511d7b4e99ed2398
Author: Harald Freudenberger <freude@linux.ibm.com>

s390/crypto: Fix use of mutex in atomic context in PAES

This commit fixes a locking violation in the PAES CTR implementation by
replacing a mutex with a binary semaphore. Mutexes are not safe to use in
atomic or interrupt contexts, where crypto operations are often invoked. It
also restructures the PAES CTR code to remove conditional locking.

> diff --git a/arch/s390/crypto/paes_s390.c b/arch/s390/crypto/paes_s390.c
> index d075b0241f1f5..10d1c56a049d6 100644
> --- a/arch/s390/crypto/paes_s390.c
> +++ b/arch/s390/crypto/paes_s390.c
> @@ -45,7 +45,7 @@ module_param_named(clrkey, pkey_clrkey_allowed, bool, 0444);
>  MODULE_PARM_DESC(clrkey, "Allow clear key material (default N)");
>  
>  static u8 *ctrblk;
> -static DEFINE_MUTEX(ctrblk_lock);
> +static DEFINE_SEMAPHORE(ctrblk_sem, 1);

[Severity: High]
This is a pre-existing issue, but while this patch successfully fixes the
mutex usage in the PAES implementation, does the standard AES CTR
implementation in arch/s390/crypto/aes_s390.c suffer from the exact same
problem?

Looking at ctr_aes_crypt() in arch/s390/crypto/aes_s390.c, it appears to
still use a mutex:

arch/s390/crypto/aes_s390.c:ctr_aes_crypt() {
    ...
    locked = mutex_trylock(&ctrblk_lock);
    ...
}

and later:

arch/s390/crypto/aes_s390.c:ctr_aes_crypt() {
    ...
    if (locked)
        mutex_unlock(&ctrblk_lock);
    ...
}

Since the AES CTR skcipher algorithm is registered as synchronous, it can be
called from softirq context, such as when processing IPsec traffic. Calling
mutex operations from softirq context violates kernel locking rules and can
trigger lockdep warnings or panics on PREEMPT_RT kernels.

Does the AES CTR implementation need a similar fix to use a binary semaphore
instead of a mutex?

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