From: Ren Wei <n05ec@lzu.edu.cn>
To: linux-crypto@vger.kernel.org
Cc: herbert@gondor.apana.org.au, davem@davemloft.net,
ardb@kernel.org, yuantan098@gmail.com, yifanwucs@gmail.com,
tomapufckgml@gmail.com, bird@lzu.edu.cn, z1652074432@gmail.com,
kanolyc@gmail.com, n05ec@lzu.edu.cn
Subject: [PATCH 1/1] crypto: authencesn: reject short ahash digests during instance creation
Date: Mon, 20 Apr 2026 16:48:25 +0800 [thread overview]
Message-ID: <cb1188757edab9b056961d4d2441be009ac73ce8.1775217403.git.kanolyc@gmail.com> (raw)
In-Reply-To: <cover.1775217403.git.kanolyc@gmail.com>
From: Yucheng Lu <kanolyc@gmail.com>
authencesn requires either a zero authsize or an authsize of at least
4 bytes because the ESN encrypt/decrypt paths always move 4 bytes of
high-order sequence number data at the end of the authenticated data.
While crypto_authenc_esn_setauthsize() already rejects explicit
non-zero authsizes in the range 1..3, crypto_authenc_esn_create()
still copied auth->digestsize into inst->alg.maxauthsize without
validating it. The AEAD core then initialized the tfm's default
authsize from that value.
As a result, selecting an ahash with digest size 1..3, such as
cbcmac(cipher_null), exposed authencesn instances whose default
authsize was invalid even though setauthsize() would have rejected the
same value. AF_ALG could then trigger the ESN tail handling with a
too-short tag and hit an out-of-bounds access.
Reject authencesn instances whose ahash digest size is in the invalid
non-zero range 1..3 so that no tfm can inherit an unsupported default
authsize.
Fixes: f15f05b0a5de ("crypto: ccm - switch to separate cbcmac driver")
Cc: stable@kernel.org
Reported-by: Yuan Tan <yuantan098@gmail.com>
Reported-by: Yifan Wu <yifanwucs@gmail.com>
Reported-by: Juefei Pu <tomapufckgml@gmail.com>
Reported-by: Xin Liu <bird@lzu.edu.cn>
Tested-by: Yuhang Zheng <z1652074432@gmail.com>
Signed-off-by: Yucheng Lu <kanolyc@gmail.com>
Signed-off-by: Ren Wei <n05ec@lzu.edu.cn>
---
crypto/authencesn.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/crypto/authencesn.c b/crypto/authencesn.c
index 542a978663b9..bf44f035f7f8 100644
--- a/crypto/authencesn.c
+++ b/crypto/authencesn.c
@@ -384,6 +384,11 @@ static int crypto_authenc_esn_create(struct crypto_template *tmpl,
goto err_free_inst;
enc = crypto_spawn_skcipher_alg_common(&ctx->enc);
+ if (auth->digestsize > 0 && auth->digestsize < 4) {
+ err = -EINVAL;
+ goto err_free_inst;
+ }
+
err = -ENAMETOOLONG;
if (snprintf(inst->alg.base.cra_name, CRYPTO_MAX_ALG_NAME,
"authencesn(%s,%s)", auth_base->cra_name,
--
2.47.3
WARNING: multiple messages have this Message-ID (diff)
From: Ren Wei <n05ec@lzu.edu.cn>
To: linux-crypto@vger.kernel.org
Cc: herbert@gondor.apana.org.au, davem@davemloft.net,
ardb@kernel.org, yifanwucs@gmail.com, tomapufckgml@gmail.com,
yuantan098@gmail.com, bird@lzu.edu.cn, z1652074432@gmail.com,
ebiggers@kernel.org, kanolyc@gmail.com, n05ec@lzu.edu.cn
Subject: [PATCH v2 1/1] crypto: authencesn: reject short ahash digests during instance creation
Date: Wed, 22 Apr 2026 21:45:04 +0800 [thread overview]
Message-ID: <cb1188757edab9b056961d4d2441be009ac73ce8.1775217403.git.kanolyc@gmail.com> (raw)
Message-ID: <20260422134504.jNOSdsNJTKN7W220mOJdfsJnW6s9-m54TjzHROVM-28@z> (raw)
In-Reply-To: <cover.1775217403.git.kanolyc@gmail.com>
From: Yucheng Lu <kanolyc@gmail.com>
authencesn requires either a zero authsize or an authsize of at least
4 bytes because the ESN encrypt/decrypt paths always move 4 bytes of
high-order sequence number data at the end of the authenticated data.
While crypto_authenc_esn_setauthsize() already rejects explicit
non-zero authsizes in the range 1..3, crypto_authenc_esn_create()
still copied auth->digestsize into inst->alg.maxauthsize without
validating it. The AEAD core then initialized the tfm's default
authsize from that value.
As a result, selecting an ahash with digest size 1..3, such as
cbcmac(cipher_null), exposed authencesn instances whose default
authsize was invalid even though setauthsize() would have rejected the
same value. AF_ALG could then trigger the ESN tail handling with a
too-short tag and hit an out-of-bounds access.
Reject authencesn instances whose ahash digest size is in the invalid
non-zero range 1..3 so that no tfm can inherit an unsupported default
authsize.
Fixes: f15f05b0a5de ("crypto: ccm - switch to separate cbcmac driver")
Cc: stable@kernel.org
Reported-by: Yifan Wu <yifanwucs@gmail.com>
Reported-by: Juefei Pu <tomapufckgml@gmail.com>
Co-developed-by: Yuan Tan <yuantan098@gmail.com>
Signed-off-by: Yuan Tan <yuantan098@gmail.com>
Suggested-by: Xin Liu <bird@lzu.edu.cn>
Tested-by: Yuhang Zheng <z1652074432@gmail.com>
Reviewed-by: Eric Biggers <ebiggers@kernel.org>
Signed-off-by: Yucheng Lu <kanolyc@gmail.com>
Signed-off-by: Ren Wei <n05ec@lzu.edu.cn>
---
changes in v2:
- move the short digest size check to immediately after
auth_base = &auth->base;
- add Reviewed-by from Eric Biggers
- fix the stable@kernel.org address typo
- Link: https://lore.kernel.org/all/cb1188757edab9b056961d4d2441be009ac73ce8.1775217403.git.kanolyc@gmail.com/
crypto/authencesn.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/crypto/authencesn.c b/crypto/authencesn.c
index 542a978663b9..f6ac9eefc7d9 100644
--- a/crypto/authencesn.c
+++ b/crypto/authencesn.c
@@ -378,6 +378,11 @@ static int crypto_authenc_esn_create(struct crypto_template *tmpl,
auth = crypto_spawn_ahash_alg(&ctx->auth);
auth_base = &auth->base;
+ if (auth->digestsize > 0 && auth->digestsize < 4) {
+ err = -EINVAL;
+ goto err_free_inst;
+ }
+
err = crypto_grab_skcipher(&ctx->enc, aead_crypto_instance(inst),
crypto_attr_alg_name(tb[2]), 0, mask);
if (err)
--
2.47.3
next parent reply other threads:[~2026-04-20 8:54 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <cover.1775217403.git.kanolyc@gmail.com>
2026-04-20 8:48 ` Ren Wei [this message]
2026-04-20 9:21 ` [PATCH 1/1] crypto: authencesn: reject short ahash digests during instance creation Ard Biesheuvel
2026-04-21 21:27 ` Eric Biggers
2026-04-22 13:45 ` [PATCH v2 " Ren Wei
2026-04-23 5:46 ` Herbert Xu
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=cb1188757edab9b056961d4d2441be009ac73ce8.1775217403.git.kanolyc@gmail.com \
--to=n05ec@lzu.edu.cn \
--cc=ardb@kernel.org \
--cc=bird@lzu.edu.cn \
--cc=davem@davemloft.net \
--cc=herbert@gondor.apana.org.au \
--cc=kanolyc@gmail.com \
--cc=linux-crypto@vger.kernel.org \
--cc=tomapufckgml@gmail.com \
--cc=yifanwucs@gmail.com \
--cc=yuantan098@gmail.com \
--cc=z1652074432@gmail.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox