lib/crypto: poly1305: Use size_t length

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>

0 files changed, 0 insertions, 0 deletions