linux-kernel - Re: [PATCH] lib/crypto: blake2b: Limit frame size workaround to GCC

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20251123092840.44c92841@pumpkin>
Date: Sun, 23 Nov 2025 09:28:40 +0000
From: david laight <david.laight@...box.com>
To: Thorsten Blum <thorsten.blum@...ux.dev>
Cc: Eric Biggers <ebiggers@...nel.org>, "Jason A. Donenfeld"
 <Jason@...c4.com>, Ard Biesheuvel <ardb@...nel.org>,
 linux-crypto@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] lib/crypto: blake2b: Limit frame size workaround to GCC
 < 12.2 on i386

On Sat, 22 Nov 2025 11:55:31 +0100
Thorsten Blum <thorsten.blum@...ux.dev> wrote:

> The GCC bug only occurred on i386 and has been resolved since GCC 12.2.
> Limit the frame size workaround to GCC < 12.2 on i386.
> 
> Signed-off-by: Thorsten Blum <thorsten.blum@...ux.dev>
> ---
>  lib/crypto/Makefile | 4 ++++
>  1 file changed, 4 insertions(+)
> 
> diff --git a/lib/crypto/Makefile b/lib/crypto/Makefile
> index b5346cebbb55..5ee36a231484 100644
> --- a/lib/crypto/Makefile
> +++ b/lib/crypto/Makefile
> @@ -33,7 +33,11 @@ obj-$(CONFIG_CRYPTO_LIB_GF128MUL)		+= gf128mul.o
>  
>  obj-$(CONFIG_CRYPTO_LIB_BLAKE2B) += libblake2b.o
>  libblake2b-y := blake2b.o
> +ifeq ($(CONFIG_X86_32),y)
> +ifeq ($(CONFIG_CC_IS_GCC)_$(call gcc-min-version, 120200),y_)
>  CFLAGS_blake2b.o := -Wframe-larger-than=4096 #  https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105930
> +endif # CONFIG_CC_IS_GCC
> +endif # CONFIG_X86_32

Isn't that just going to cause a run-time stack overflow?
The compile-time check is a vague attempt to stop run-type overflow by limiting
the largest single stack frames.

I can't remember the kernel stack size for x86-32, might only be 8k.

The only real solution is to either fix the source so it doesn't blow
the stack (I suspect the code is 'unrolled' and the spills everything
to stack - making it slow), or just disable the code from the build.

	David

>  ifeq ($(CONFIG_CRYPTO_LIB_BLAKE2B_ARCH),y)
>  CFLAGS_blake2b.o += -I$(src)/$(SRCARCH)
>  libblake2b-$(CONFIG_ARM) += arm/blake2b-neon-core.o