Re: [PATCH] stable: crypto: sha256 - fix crash at kexec

[Eric Biggers <ebiggers@kernel.org>]

On Wed, Oct 01, 2025 at 09:07:07AM -0700, Breno Leitao wrote:
> Loading a large (~2.1G) files with kexec crashes the host with when
> running:
> 
>   # kexec --load kernel --initrd initrd_with_2G_or_more
> 
>   UBSAN: signed-integer-overflow in ./include/crypto/sha256_base.h:64:19
>   34152083 * 64 cannot be represented in type 'int'
>   ...
>   BUG: unable to handle page fault for address: ff9fffff83b624c0
>   sha256_update (lib/crypto/sha256.c:137)
>   crypto_sha256_update (crypto/sha256_generic.c:40)
>   kexec_calculate_store_digests (kernel/kexec_file.c:769)
>   __se_sys_kexec_file_load (kernel/kexec_file.c:397 kernel/kexec_file.c:332)
>   ...
> 
> (Line numbers based on commit da274362a7bd9 ("Linux 6.12.49")
> 
> This is not happening upstream (v6.16+), given that `block` type was
> upgraded from "int" to "size_t" in commit 74a43a2cf5e8 ("crypto:
> lib/sha256 - Move partial block handling out")
> 
> Upgrade the block type similar to the commit above, avoiding hitting the
> overflow.
> 
> This patch is only suitable for the stable tree, and before 6.16, which
> got commit 74a43a2cf5e8 ("crypto: lib/sha256 - Move partial block
> handling out")
> 
> Signed-off-by: Breno Leitao <leitao@debian.org>
> Fixes: 11b8d5ef9138 ("crypto: sha256 - implement base layer for SHA-256") # not after v6.16
> Reported-by: Michael van der Westhuizen <rmikey@meta.com>
> Reported-by: Tobias Fleig <tfleig@meta.com>
> ---
>  include/crypto/sha256_base.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/include/crypto/sha256_base.h b/include/crypto/sha256_base.h
> index e0418818d63c8..fa63af10102b2 100644
> --- a/include/crypto/sha256_base.h
> +++ b/include/crypto/sha256_base.h
> @@ -44,7 +44,7 @@ static inline int lib_sha256_base_do_update(struct sha256_state *sctx,
>  	sctx->count += len;
>  
>  	if (unlikely((partial + len) >= SHA256_BLOCK_SIZE)) {
> -		int blocks;
> +		size_t blocks;
>  
>  		if (partial) {
>  			int p = SHA256_BLOCK_SIZE - partial;
> 
> ---

This looks fine, but technically 'unsigned int' would be more
appropriate here, given the context.  If we look at the whole function
in 6.12, we can see that it took an 'unsigned int' length:

 static inline int lib_sha256_base_do_update(struct sha256_state *sctx,
 					    const u8 *data,
 					    unsigned int len,
 					    sha256_block_fn *block_fn)
 {
 	unsigned int partial = sctx->count % SHA256_BLOCK_SIZE;
 
 	sctx->count += len;
 
 	if (unlikely((partial + len) >= SHA256_BLOCK_SIZE)) {
-		int blocks;
+		size_t blocks;
 
 		if (partial) {
 			int p = SHA256_BLOCK_SIZE - partial;
 
 			memcpy(sctx->buf + partial, data, p);
 			data += p;
 			len -= p;
 
 			block_fn(sctx, sctx->buf, 1);
 		}
 
 		blocks = len / SHA256_BLOCK_SIZE;
 		len %= SHA256_BLOCK_SIZE;
 
 		if (blocks) {
 			block_fn(sctx, data, blocks);
 			data += blocks * SHA256_BLOCK_SIZE;
 		}
 		partial = 0;
 	}
 	if (len)
 		memcpy(sctx->buf + partial, data, len);
 
 	return 0;
 }

This also suggests that files with lengths greater than UINT_MAX are
still broken.  Is that okay?

Anyway, I'm glad that I fixed all these functions to use size_t lengths
in newer kernels...

- Eric