From: Herbert Xu <herbert@gondor.apana.org.au>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Vegard Nossum <vegard.nossum@oracle.com>,
"David S. Miller" <davem@davemloft.net>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Linux Crypto Mailing List <linux-crypto@vger.kernel.org>
Subject: [PATCH] crypto: hash - Make HASH_MAX_DESCSIZE a bit more obvious
Date: Mon, 11 Aug 2025 12:44:00 +0800 [thread overview]
Message-ID: <aJl1EIoSHnZRIQNO@gondor.apana.org.au> (raw)
In-Reply-To: <CAHk-=wjn5AtuNixX36qDGWumG4LiSDuuqfbaGH2RZu2ThXzV-A@mail.gmail.com>
On Sun, Aug 10, 2025 at 07:51:56AM +0300, Linus Torvalds wrote:
>
> Yeah, that should have been in the commit message somewhere.
>
> And honestly, it should have been in the code too. Having very random
> constants in header files with no explanation for them is not great.
The patch below should make the constant a bit more obvious.
> The dynamic check may be the right thing to do regardless, but when
> fixing outright bugs, at least document what went wrong and why. Not
> just "360 was too small for X, so it is now 361".
The dynamic check has always been there (see commit b68a7ec1e9a3).
So this fix wasn't about a buffer overflow, rather it was to make
s390 sha3-224 work again as it got caught by the dynamic check.
Cheers,
---8<---
Move S390_SHA_CTX_SIZE into crypto/hash.h so that the derivation
of HASH_MAX_DESCSIZE is less cryptic.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
diff --git a/arch/s390/crypto/sha.h b/arch/s390/crypto/sha.h
index cadb4b13622a..b9cd9572dd35 100644
--- a/arch/s390/crypto/sha.h
+++ b/arch/s390/crypto/sha.h
@@ -10,14 +10,15 @@
#ifndef _CRYPTO_ARCH_S390_SHA_H
#define _CRYPTO_ARCH_S390_SHA_H
+#include <crypto/hash.h>
#include <crypto/sha2.h>
#include <crypto/sha3.h>
+#include <linux/build_bug.h>
#include <linux/types.h>
/* must be big enough for the largest SHA variant */
#define CPACF_MAX_PARMBLOCK_SIZE SHA3_STATE_SIZE
#define SHA_MAX_BLOCK_SIZE SHA3_224_BLOCK_SIZE
-#define S390_SHA_CTX_SIZE sizeof(struct s390_sha_ctx)
struct s390_sha_ctx {
u64 count; /* message length in bytes */
@@ -42,4 +43,9 @@ int s390_sha_update_blocks(struct shash_desc *desc, const u8 *data,
int s390_sha_finup(struct shash_desc *desc, const u8 *src, unsigned int len,
u8 *out);
+static inline void __check_s390_sha_ctx_size(void)
+{
+ BUILD_BUG_ON(S390_SHA_CTX_SIZE != sizeof(struct s390_sha_ctx));
+}
+
#endif
diff --git a/include/crypto/hash.h b/include/crypto/hash.h
index ed63b904837d..44d407cb0c90 100644
--- a/include/crypto/hash.h
+++ b/include/crypto/hash.h
@@ -177,14 +177,26 @@ struct shash_desc {
#define HASH_MAX_DIGESTSIZE 64
+/*
+ * The size of a core hash state and a partial block. The final byte
+ * is the length of the partial block.
+ */
+#define HASH_STATE_AND_BLOCK(state, block) ((state) + (block) + 1)
+
+
/* Worst case is sha3-224. */
-#define HASH_MAX_STATESIZE 200 + 144 + 1
+#define HASH_MAX_STATESIZE HASH_STATE_AND_BLOCK(200, 144)
+
+/* This needs to match arch/s390/crypto/sha.h. */
+#define S390_SHA_CTX_SIZE 216
/*
* Worst case is hmac(sha3-224-s390). Its context is a nested 'shash_desc'
* containing a 'struct s390_sha_ctx'.
*/
-#define HASH_MAX_DESCSIZE (sizeof(struct shash_desc) + 361)
+#define SHA3_224_S390_DESCSIZE HASH_STATE_AND_BLOCK(S390_SHA_CTX_SIZE, 144)
+#define HASH_MAX_DESCSIZE (sizeof(struct shash_desc) + \
+ SHA3_224_S390_DESCSIZE)
#define MAX_SYNC_HASH_REQSIZE (sizeof(struct ahash_request) + \
HASH_MAX_DESCSIZE)
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
next prev parent reply other threads:[~2025-08-11 4:44 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-08 5:41 [GIT PULL] Crypto Fixes for 6.17 Herbert Xu
2025-08-09 4:32 ` Linus Torvalds
2025-08-09 18:22 ` Vegard Nossum
2025-08-10 4:51 ` Linus Torvalds
2025-08-11 4:44 ` Herbert Xu [this message]
2025-08-11 7:10 ` [PATCH] crypto: hash - Make HASH_MAX_DESCSIZE a bit more obvious Linus Torvalds
2025-08-11 16:57 ` Eric Biggers
2025-08-09 5:19 ` [GIT PULL] Crypto Fixes for 6.17 pr-tracker-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=aJl1EIoSHnZRIQNO@gondor.apana.org.au \
--to=herbert@gondor.apana.org.au \
--cc=davem@davemloft.net \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@linux-foundation.org \
--cc=vegard.nossum@oracle.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