linux-kernel - Re: [PATCH] lib/crypto/poly1305: Fix arm64's poly1305_blocks

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <aE-PDfmowagPegen@gondor.apana.org.au>
Date: Mon, 16 Jun 2025 11:27:09 +0800
From: Herbert Xu <herbert@...dor.apana.org.au>
To: Eric Biggers <ebiggers@...nel.org>
Cc: linux-crypto@...r.kernel.org, linux-kernel@...r.kernel.org,
	linux-arm-kernel@...ts.infradead.org, Jason@...c4.com,
	ardb@...nel.org, kent.overstreet@...ux.dev
Subject: Re: [PATCH] lib/crypto/poly1305: Fix arm64's poly1305_blocks_arch()

Eric Biggers <ebiggers@...nel.org> wrote:
> From: Eric Biggers <ebiggers@...gle.com>
> 
> For some reason arm64's Poly1305 code got changed to ignore the padbit
> argument.  As a result, the output is incorrect when the message length
> is not a multiple of 16 (which is not reached with the standard
> ChaCha20Poly1305, but bcachefs could reach this).  Fix this.

Sorry, it was a cut-n-paste error since I copy the code from
the update function where the padbit is always 1.

> diff --git a/arch/arm64/lib/crypto/poly1305-glue.c b/arch/arm64/lib/crypto/poly1305-glue.c
> index 6a661cf048213..c9a74766785bd 100644
> --- a/arch/arm64/lib/crypto/poly1305-glue.c
> +++ b/arch/arm64/lib/crypto/poly1305-glue.c
> @@ -36,18 +36,18 @@ void poly1305_blocks_arch(struct poly1305_block_state *state, const u8 *src,
>        if (static_branch_likely(&have_neon)) {
>                do {
>                        unsigned int todo = min_t(unsigned int, len, SZ_4K);
> 
>                        kernel_neon_begin();
> -                       poly1305_blocks_neon(state, src, todo, 1);
> +                       poly1305_blocks_neon(state, src, todo, padbit);

This would do the wrong thing if someone ever tried to pad a
message more than 4K and called the block function with padbit == 0.
Fortunately it can't happen today as there is no digest interface
to poly1305.

Looking around it seems that this pattern is replicated across
all of our poly1305 implementations so it isn't a big deal.

I presume you will be picking this up via the lib/crypto tree?

Thanks,
-- 
Email: Herbert Xu <herbert@...dor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt