lib/crypto/poly1305: Fix arm64's poly1305_blocks_arch()

PATCH Applied Eric Biggers 3 participants 5 messages Jun 16, 2025 – Jun 17, 2025

Subsystems (2)

Crypto API arm64

lore

Share & tools

lore

Eric Biggers

author

2025-06-16 01:08 UTC #0 lore raw

PATCH 1/1 lib/crypto/poly1305: Fix arm64's poly1305_blocks_arch()

From: Eric Biggers <[email protected]>

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.

Fixes a59e5468a921 ("crypto: arm64/poly1305 - Add block-only interface")

Reported-by Kent Overstreet <[email protected]>

Signed-off-by Eric Biggers <[email protected]>

---
 arch/arm64/lib/crypto/poly1305-glue.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

arch/arm64/lib/crypto/poly1305-glue.c +2 -2

index 6a661cf048213..c9a74766785bd 100644
@@ -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);
 			kernel_neon_end();
 
 			len -= todo;
 			src += todo;
 		} while (len);
 	} else
-		poly1305_blocks(state, src, len, 1);
+		poly1305_blocks(state, src, len, padbit);
 }
 EXPORT_SYMBOL_GPL(poly1305_blocks_arch);
 
 bool poly1305_is_arch_optimized(void)
 {

base-commit: 19272b37aa4f83ca52bdf9c16d5d81bdd1354494

Signature · 1 line

2.49.0

Kent Overstreet

Tested-by on v1 1/1

2025-06-16 01:23 UTC #1 lore raw

Quoted 10 lines · Eric Biggers

From: Eric Biggers <[email protected]>
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.
Fixes a59e5468a921 ("crypto: arm64/poly1305 - Add block-only interface")
Reported-by Kent Overstreet <[email protected]>
Signed-off-by Eric Biggers <[email protected]>

Thanks for the quick fix :)

Tested-by Kent Overstreet <[email protected]>

Quoted 34 lines

---
 arch/arm64/lib/crypto/poly1305-glue.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

arch/arm64/lib/crypto/poly1305-glue.c +2 -2

index 6a661cf048213..c9a74766785bd 100644
@@ -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);
 			kernel_neon_end();
 
 			len -= todo;
 			src += todo;
 		} while (len);
 	} else
-		poly1305_blocks(state, src, len, 1);
+		poly1305_blocks(state, src, len, padbit);
 }
 EXPORT_SYMBOL_GPL(poly1305_blocks_arch);
 
 bool poly1305_is_arch_optimized(void)
 {

base-commit: 19272b37aa4f83ca52bdf9c16d5d81bdd1354494

Signature · 1 line

2.49.0

Herbert Xu

maintainer

2025-06-16 03:27 UTC #2 lore raw

In reply to Eric Biggers

Quoted 6 lines · Eric Biggers

From: Eric Biggers <[email protected]>
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.

arch/arm64/lib/crypto/poly1305-glue.c void poly1305_blocks_arch(struct poly1305_block_state *state, const u8 *src, · line 41

Quoted 12 lines

arch/arm64/lib/crypto/poly1305-glue.c +1 -1

index 6a661cf048213..c9a74766785bd 100644
@@ -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,

Signature · 3 lines

Email: Herbert Xu <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Eric Biggers

author

2025-06-16 04:00 UTC #3 lore raw

Quoted 20 lines · Herbert Xu

Quoted 6 lines · Eric Biggers
From: Eric Biggers <[email protected]>
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.
Quoted 9 lines
arch/arm64/lib/crypto/poly1305-glue.c +0 -0
index 6a661cf048213..c9a74766785bd 100644
@@ -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);
 

Quoted 8 lines

arch/arm64/lib/crypto/poly1305-glue.c void poly1305_blocks_arch(struct poly1305_block_state *state, const u8 *src, · line 41
Quoted 3 lines
arch/arm64/lib/crypto/poly1305-glue.c +1 -1
                       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.

The final partial block is (and needs to be) processed with its own call to poly1305_blocks().

Quoted 4 lines

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?

Yes.

- Eric

Eric Biggers

author Applied

2025-06-17 03:27 UTC #4 lore raw

In reply to Eric Biggers

Quoted 7 lines · Eric Biggers

From: Eric Biggers <[email protected]>
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.

Quoted 6 lines

Fixes a59e5468a921 ("crypto: arm64/poly1305 - Add block-only interface")
Reported-by Kent Overstreet <[email protected]>
Signed-off-by Eric Biggers <[email protected]>
---
 arch/arm64/lib/crypto/poly1305-glue.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

Applied to https://git.kernel.org/pub/scm/linux/kernel/git/ebiggers/linux.git/log/?h=libcrypto-fixes

- Eric