]> git.ipfire.org Git - thirdparty/linux.git/commit
lib/crypto: x86/blake2s: Fix 32-bit arg treated as 64-bit
authorEric Biggers <ebiggers@kernel.org>
Sun, 2 Nov 2025 23:42:04 +0000 (15:42 -0800)
committerEric Biggers <ebiggers@kernel.org>
Thu, 6 Nov 2025 04:30:51 +0000 (20:30 -0800)
commit2f22115709fc7ebcfa40af3367a508fbbd2f71e9
tree7066791c2f6dc544e868069abf9ed22fb531bae9
parent95ce85de0b8c8a1192c692cbd5948e4dcbc1563f
lib/crypto: x86/blake2s: Fix 32-bit arg treated as 64-bit

In the C code, the 'inc' argument to the assembly functions
blake2s_compress_ssse3() and blake2s_compress_avx512() is declared with
type u32, matching blake2s_compress().  The assembly code then reads it
from the 64-bit %rcx.  However, the ABI doesn't guarantee zero-extension
to 64 bits, nor do gcc or clang guarantee it.  Therefore, fix these
functions to read this argument from the 32-bit %ecx.

In theory, this bug could have caused the wrong 'inc' value to be used,
causing incorrect BLAKE2s hashes.  In practice, probably not: I've fixed
essentially this same bug in many other assembly files too, but there's
never been a real report of it having caused a problem.  In x86_64, all
writes to 32-bit registers are zero-extended to 64 bits.  That results
in zero-extension in nearly all situations.  I've only been able to
demonstrate a lack of zero-extension with a somewhat contrived example
involving truncation, e.g. when the C code has a u64 variable holding
0x1234567800000040 and passes it as a u32 expecting it to be truncated
to 0x40 (64).  But that's not what the real code does, of course.

Fixes: ed0356eda153 ("crypto: blake2s - x86_64 SIMD implementation")
Cc: stable@vger.kernel.org
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Link: https://lore.kernel.org/r/20251102234209.62133-2-ebiggers@kernel.org
Signed-off-by: Eric Biggers <ebiggers@kernel.org>
lib/crypto/x86/blake2s-core.S