From: Vladimir Kukharenko via B4 Relay <devnull+vladimir.genproof.com@kernel.org>
To: Eric Biggers <ebiggers@kernel.org>,
"Jason A. Donenfeld" <Jason@zx2c4.com>,
Ard Biesheuvel <ardb@kernel.org>
Cc: linux-crypto@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-mips@vger.kernel.org,
Vladimir Kukharenko <vladimir@genproof.com>
Subject: [PATCH 2/2] lib/crypto: mips/chacha: Handle lengths of 2 GiB or more
Date: Wed, 14 Oct 2026 20:34:22 +0000 [thread overview]
Message-ID: <20261014-libcrypto-chacha-32bit-2gib-v1-2-e0719ca0be89@genproof.com> (raw)
In-Reply-To: <20261014-libcrypto-chacha-32bit-2gib-v1-0-e0719ca0be89@genproof.com>
From: Vladimir Kukharenko <vladimir@genproof.com>
The MIPS ChaCha assembly, which is chacha_crypt_arch() itself, tests
the remaining length with signed branches, so for 2 GiB + 64 bytes or
more it takes the final partial block path too early and processes less
than requested. It is only used on 32-bit kernels, where size_t is 32
bits, so declaring the length as size_t does not avoid this. No
in-tree caller passes such lengths.
The partial block code also keeps the remaining length as a negative
value, so instead of changing the assembly, rename it to
chacha_crypt_mips() and add a C chacha_crypt_arch() that passes it at
most 1 GiB per call.
Tested in QEMU user mode: with a length of 0xfffff045 the assembly
processed about 4 KiB and advanced the block counter by 64; with the
same 1 GiB loop in C, a 1.25 GiB + 4101 byte buffer matches a C
reference. An LLM review of this code found the bug.
Assisted-by: LLM
Signed-off-by: Vladimir Kukharenko <vladimir@genproof.com>
---
lib/crypto/mips/chacha-core.S | 8 ++++----
lib/crypto/mips/chacha.h | 20 +++++++++++++++++++-
2 files changed, 23 insertions(+), 5 deletions(-)
diff --git a/lib/crypto/mips/chacha-core.S b/lib/crypto/mips/chacha-core.S
index 706aeb850fb0..1a2253d91af7 100644
--- a/lib/crypto/mips/chacha-core.S
+++ b/lib/crypto/mips/chacha-core.S
@@ -196,9 +196,9 @@ CONCAT3(.Lchacha_mips_xor_aligned_, PLUS_ONE(x), _b: ;) \
.text
.set reorder
.set noat
-.globl chacha_crypt_arch
-.ent chacha_crypt_arch
-chacha_crypt_arch:
+.globl chacha_crypt_mips
+.ent chacha_crypt_mips
+chacha_crypt_mips:
.frame $sp, STACK_SIZE, $ra
/* Load number of rounds */
@@ -414,7 +414,7 @@ chacha_crypt_arch:
/* Jump table */
FOR_EACH_WORD(JMPTBL_UNALIGNED)
-.end chacha_crypt_arch
+.end chacha_crypt_mips
.set at
/* Input arguments
diff --git a/lib/crypto/mips/chacha.h b/lib/crypto/mips/chacha.h
index 5a565d0a8c26..15b39c744c28 100644
--- a/lib/crypto/mips/chacha.h
+++ b/lib/crypto/mips/chacha.h
@@ -6,8 +6,26 @@
*/
#include <linux/kernel.h>
+#include <linux/sizes.h>
-asmlinkage void chacha_crypt_arch(struct chacha_state *state, u8 *dst,
+asmlinkage void chacha_crypt_mips(struct chacha_state *state, u8 *dst,
const u8 *src, size_t bytes, int nrounds);
asmlinkage void hchacha_block_arch(const struct chacha_state *state,
u32 out[HCHACHA_OUT_WORDS], int nrounds);
+
+static void chacha_crypt_arch(struct chacha_state *state, u8 *dst,
+ const u8 *src, size_t bytes, int nrounds)
+{
+ /*
+ * chacha_crypt_mips() compares the length as a signed value, so pass
+ * it at most 1 GiB at a time.
+ */
+ do {
+ size_t todo = min(bytes, SZ_1G);
+
+ chacha_crypt_mips(state, dst, src, todo, nrounds);
+ bytes -= todo;
+ src += todo;
+ dst += todo;
+ } while (bytes);
+}
--
2.43.0
next prev parent reply other threads:[~2026-10-14 20:39 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-14 20:34 [PATCH 0/2] lib/crypto: chacha: Handle lengths of 2 GiB or more on 32-bit arm and MIPS Vladimir Kukharenko via B4 Relay
2026-10-14 20:34 ` [PATCH 1/2] lib/crypto: arm/chacha: Handle lengths of 2 GiB or more in scalar code Vladimir Kukharenko via B4 Relay
2026-10-14 20:34 ` Vladimir Kukharenko via B4 Relay [this message]
2026-10-16 7:28 ` [PATCH 0/2] lib/crypto: chacha: Handle lengths of 2 GiB or more on 32-bit arm and MIPS Eric Biggers
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20261014-libcrypto-chacha-32bit-2gib-v1-2-e0719ca0be89@genproof.com \
--to=devnull+vladimir.genproof.com@kernel.org \
--cc=Jason@zx2c4.com \
--cc=ardb@kernel.org \
--cc=ebiggers@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mips@vger.kernel.org \
--cc=vladimir@genproof.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®