From: sashiko-bot@kernel.org
To: "Heiko Carstens" <hca@linux.ibm.com>
Cc: linux-s390@vger.kernel.org, "Vasily Gorbik" <gor@linux.ibm.com>,
"Heiko Carstens" <hca@linux.ibm.com>,
"Alexander Gordeev" <agordeev@linux.ibm.com>
Subject: Re: [PATCH 1/3] s390/crypto: Rework ctr_aes_crypt() to remove conditional locking
Date: Tue, 04 Aug 2026 11:44:50 +0000 [thread overview]
Message-ID: <20260804114451.3EFAF1F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260804113736.1423667-2-hca@linux.ibm.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] The error code returned by `skcipher_walk_virt()` is unconditionally overwritten by the return value of `__ctr_aes_crypt()`, silently dropping errors.
--
--- Patch [1]: [PATCH 1/3] s390/crypto: Rework ctr_aes_crypt() to remove conditional locking ---
commit 83af1e74cacdeddf34088df594504204b40a3d99
Author: Heiko Carstens <hca@linux.ibm.com>
s390/crypto: Rework ctr_aes_crypt() to remove conditional locking
This commit removes conditional locking in ctr_aes_crypt() to address a Clang
thread-safety warning. The block processing loop is moved into a new helper
function __ctr_aes_crypt().
> diff --git a/arch/s390/crypto/aes_s390.c b/arch/s390/crypto/aes_s390.c
> index 62edc66d54788..4b7e47423e892 100644
> --- a/arch/s390/crypto/aes_s390.c
> +++ b/arch/s390/crypto/aes_s390.c
[ ... ]
> @@ -589,37 +604,53 @@ static int ctr_aes_crypt(struct skcipher_request *req)
> {
> struct crypto_skcipher *tfm = crypto_skcipher_reqtfm(req);
> struct s390_aes_ctx *sctx = crypto_skcipher_ctx(tfm);
> - u8 buf[AES_BLOCK_SIZE], *ctrptr;
> struct skcipher_walk walk;
> - unsigned int n, nbytes;
> - int ret, locked;
> + u8 buf[AES_BLOCK_SIZE];
> + unsigned int nbytes;
> + int ret;
>
> if (unlikely(!sctx->fc))
> return fallback_skcipher_crypt(sctx, req, 0);
>
> - locked = mutex_trylock(&ctrblk_lock);
> -
> ret = skcipher_walk_virt(&walk, req, false);
> - while ((nbytes = walk.nbytes) >= AES_BLOCK_SIZE) {
> - n = AES_BLOCK_SIZE;
[ ... ]
> - crypto_inc(walk.iv, AES_BLOCK_SIZE);
> - ret = skcipher_walk_done(&walk, nbytes - n);
> - }
> - if (locked)
> +
> + if (mutex_trylock(&ctrblk_lock)) {
> + ret = __ctr_aes_crypt(sctx, &walk, true);
> mutex_unlock(&ctrblk_lock);
> + } else {
> + ret = __ctr_aes_crypt(sctx, &walk, false);
> + }
[Severity: High]
Does this code accidentally drop the error code from skcipher_walk_virt()?
If skcipher_walk_virt() fails and returns a negative error code (e.g. -ENOMEM
or -EINVAL), ret is immediately overwritten by the return value of
__ctr_aes_crypt().
Because walk.nbytes is 0 on error, __ctr_aes_crypt() will skip its loop
and return 0, converting the error into a success:
arch/s390/crypto/aes_s390.c:__ctr_aes_crypt() {
int ret = 0;
while ((nbytes = walk->nbytes) >= AES_BLOCK_SIZE) {
...
}
return ret;
}
Could this result in callers silently treating unencrypted data as a
successful cryptographic operation?
> +
> + nbytes = walk.nbytes;
> /*
> * final block may be < AES_BLOCK_SIZE, copy only nbytes
> */
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260804113736.1423667-1-hca@linux.ibm.com?part=1
next prev parent reply other threads:[~2026-08-04 11:44 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-04 11:37 [PATCH 0/3] s390/crypto: Enable CONTEXT_ANALYSIS Heiko Carstens
2026-08-04 11:37 ` [PATCH 1/3] s390/crypto: Rework ctr_aes_crypt() to remove conditional locking Heiko Carstens
2026-08-04 11:44 ` sashiko-bot [this message]
2026-08-04 11:37 ` [PATCH 2/3] s390/crypto: Rework ctr_paes_do_crypt() " Heiko Carstens
2026-08-04 11:47 ` sashiko-bot
2026-08-04 12:47 ` Heiko Carstens
2026-08-05 8:47 ` Harald Freudenberger
2026-08-04 11:37 ` [PATCH 3/3] s390/crypto: Enable CONTEXT_ANALYSIS Heiko Carstens
2026-08-04 11:45 ` sashiko-bot
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260804114451.3EFAF1F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=agordeev@linux.ibm.com \
--cc=gor@linux.ibm.com \
--cc=hca@linux.ibm.com \
--cc=linux-s390@vger.kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.