diff options
| author | Eric Biggers <ebiggers@kernel.org> | 2025-11-02 15:42:04 -0800 |
|---|---|---|
| committer | Eric Biggers <ebiggers@kernel.org> | 2025-11-05 20:30:51 -0800 |
| commit | 2f22115709fc7ebcfa40af3367a508fbbd2f71e9 (patch) | |
| tree | 7066791c2f6dc544e868069abf9ed22fb531bae9 /drivers/gpu/drm/amd/amdgpu/amdgpu_jpeg.c | |
| parent | 95ce85de0b8c8a1192c692cbd5948e4dcbc1563f (diff) | |
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>
Diffstat (limited to 'drivers/gpu/drm/amd/amdgpu/amdgpu_jpeg.c')
0 files changed, 0 insertions, 0 deletions
