From: Eric Biggers <ebiggers@kernel.org>
To: stable@vger.kernel.org
Cc: linux-crypto@vger.kernel.org, linux-mips@vger.kernel.org,
Eric Biggers <ebiggers@kernel.org>,
Ard Biesheuvel <ardb@kernel.org>
Subject: [PATCH 6.12,6.6,6.1] lib/crypto: mips: Disable Octeon SHA code on little-endian kernels
Date: Tue, 10 Nov 2026 13:54:04 -0800 [thread overview]
Message-ID: <20261110215404.37415-1-ebiggers@kernel.org> (raw)
commit dd2a4edb26e1c78823c50ba10c42f2d3de2e5ec4 upstream.
Kernels built for the MIPS64-based Cavium Octeon SoCs are normally
big-endian, but little-endian builds are also supported. Currently, the
SHA-1, SHA-256, and SHA-512 code using the Octeon crypto co-processor is
enabled in both builds.
This code is untestable without the hardware. However, based on the
code itself, it is implausible that it computes hash values correctly in
little-endian builds. Such builds write many incorrect values to COP2:
- SHA-1 and SHA-256: The 64-bit integer that contains the last two
32-bit message words of each block is written to COP2 entirely
byte-reflected, due to missing endianness conversion in
octeon_sha1_start() and octeon_sha256_start() to compensate for
using native 64-bit loads from the message bytes. This differs from
all the earlier message words which are written correctly.
Furthermore, the state is written to COP2 with each 32-bit word
byte-reflected within each 64-bit integer, due to incorrect use of
64-bit endianness conversion in write_octeon_64bit_hash_dword() when
the state is kept in memory in native-endian 32-bit words.
- SHA-512: All the 64-bit message words are written to COP2
byte-reflected, due to missing endianness conversion in
write_octeon_64bit_block_sha512() and octeon_sha512_start(). The
SHA-512 state words seem to be written correctly.
Big-endian kernels aren't affected by these bugs. These bugs also
aren't new; this code has been broken on little-endian ever since it and
Octeon little-endian support were first added in v4.1.
Commit d2a948d2db68 ("MIPS: Octeon: Make octeon-md5 driver
endian-agnostic") made the MD5 code work on little-endian kernels by
adding 64-bit endianness conversions to the COP2 macros used by MD5
(some of which are shared by SHA-1 and SHA-256, despite those algorithms
keeping the state words in native-endian instead of MD5's little-endian,
causing some of the strange behavior described above). However, SHA-1,
SHA-256, and SHA-512 were never fixed to work on little-endian kernels.
Therefore, disable the Octeon SHA-1, SHA-256, and SHA-512 code in
little-endian kernels. This causes the generic code that actually
computes hash values correctly to be used instead.
Fixes: 82be2dcfa6a1 ("crypto: octeon - add SHA1 module")
Fixes: c3d0def62001 ("crypto: octeon - add SHA256 module")
Fixes: fbaa4dfd51a0 ("crypto: octeon - add SHA512 module")
Cc: stable@vger.kernel.org
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Link: https://patch.msgid.link/20261022054450.20746-1-ebiggers@kernel.org
Signed-off-by: Eric Biggers <ebiggers@kernel.org>
---
arch/mips/crypto/Kconfig | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/mips/crypto/Kconfig b/arch/mips/crypto/Kconfig
index ee9604fd20372..f951a75dfef32 100644
--- a/arch/mips/crypto/Kconfig
+++ b/arch/mips/crypto/Kconfig
@@ -34,7 +34,7 @@ config CRYPTO_MD5_OCTEON
config CRYPTO_SHA1_OCTEON
tristate "Hash functions: SHA-1 (OCTEON)"
- depends on CPU_CAVIUM_OCTEON
+ depends on CPU_CAVIUM_OCTEON && CPU_BIG_ENDIAN
select CRYPTO_SHA1
select CRYPTO_HASH
help
@@ -44,7 +44,7 @@ config CRYPTO_SHA1_OCTEON
config CRYPTO_SHA256_OCTEON
tristate "Hash functions: SHA-224 and SHA-256 (OCTEON)"
- depends on CPU_CAVIUM_OCTEON
+ depends on CPU_CAVIUM_OCTEON && CPU_BIG_ENDIAN
select CRYPTO_SHA256
select CRYPTO_HASH
help
@@ -54,7 +54,7 @@ config CRYPTO_SHA256_OCTEON
config CRYPTO_SHA512_OCTEON
tristate "Hash functions: SHA-384 and SHA-512 (OCTEON)"
- depends on CPU_CAVIUM_OCTEON
+ depends on CPU_CAVIUM_OCTEON && CPU_BIG_ENDIAN
select CRYPTO_SHA512
select CRYPTO_HASH
help
base-commit: d3417611a3b40b7f04a29e558cebac2bf69889d7
--
2.56.0
reply other threads:[~2026-11-10 21:54 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=20261110215404.37415-1-ebiggers@kernel.org \
--to=ebiggers@kernel.org \
--cc=ardb@kernel.org \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-mips@vger.kernel.org \
--cc=stable@vger.kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.