mirror of
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
synced 2026-10-26 10:57:38 +08:00
Eric Biggers
0b58c136c2
Upgrade the Poly1305 functions from 32-bit lengths to size_t. 'size_t' is the best practice for buffer lengths, and it's what the rest of the crypto library uses. Moreover, all the 64-bit Poly1305 assembly functions actually already treated the length as 64-bit, despite it being declared as 32-bit in C on arm64, mips64, ppc64, and riscv64: - On arm64, this caused unspecified behavior due to the high 32 bits having an unspecified value in that architecture's ABI. However, in practice these bits are always zero and no issue occurred. (ppc64 was fine too, since there the ABI zero-extends 32-bit arguments.) - On mips64 and riscv64, this caused incorrect behavior on lengths above S32_MAX, due to the sign extension done by those architectures' ABIs. Note that no current callers pass lengths over S32_MAX. Also, the expression 'desc->buflen + nbytes >= POLY1305_BLOCK_SIZE' in poly1305_update() could overflow if nbytes was in [UINT_MAX - 14, UINT_MAX]. Note that again, no current callers pass lengths this large. These issues date to the original introduction of the Poly1305 code. However, as noted above, they don't have any real-world impact currently; so this is an API robustness improvement only. Reported-by: Vladimir Kukharenko <vladimir@genproof.com> Closes: https://lore.kernel.org/r/20261012-libcrypto-4gib-lengths-v1-0-ea566c129a2e@genproof.com Tested-by: Vladimir Kukharenko <vladimir@genproof.com> Link: https://patch.msgid.link/20261014152604.323310-2-ebiggers@kernel.org Signed-off-by: Eric Biggers <ebiggers@kernel.org>