summaryrefslogtreecommitdiff
path: root/tools/perf/scripts/python/task-analyzer.py
diff options
context:
space:
mode:
authorEric Biggers <ebiggers@kernel.org>2026-10-14 17:26:04 +0200
committerEric Biggers <ebiggers@kernel.org>2026-10-15 23:16:46 -0700
commite42003dba6dd11380b8c2a39f3bc1bf11a6d0b0f (patch)
treec87f6e89cac6a039590745056d6409ce09bd3720 /tools/perf/scripts/python/task-analyzer.py
parent0b58c136c2f9067b1a5253bffa322f6bf3e2cc74 (diff)
downloadlinux-e42003dba6dd11380b8c2a39f3bc1bf11a6d0b0f.tar.gz
linux-e42003dba6dd11380b8c2a39f3bc1bf11a6d0b0f.zip
lib/crypto: chacha: Use size_t length
Upgrade the ChaCha 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 ChaCha assembly functions actually already treated the length as 64-bit, despite it being declared as 32-bit in C on arm64, ppc64, and x86_64. For arm64 and x86_64, this caused unspecified behavior due to the high 32 bits of the corresponding register having an unspecified value in those architectures' ABIs. 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.) These issues date to the original introduction of the ChaCha 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-3-ebiggers@kernel.org Signed-off-by: Eric Biggers <ebiggers@kernel.org>
Diffstat (limited to 'tools/perf/scripts/python/task-analyzer.py')
0 files changed, 0 insertions, 0 deletions