[PATCH] lib/crypto: poly1305: Restore dependency of arch code on !KMSAN

3 views
Skip to first unread message

Eric Biggers

unread,
Oct 21, 2025, 11:37:29 PMOct 21
to linux-...@vger.kernel.org, linux-...@vger.kernel.org, Ard Biesheuvel, Jason A . Donenfeld, Herbert Xu, Pei Xiao, Alexander Potapenko, kasa...@googlegroups.com, Eric Biggers, syzbot+01fcd3...@syzkaller.appspotmail.com
Restore the dependency of the architecture-optimized Poly1305 code on
!KMSAN. It was dropped by commit b646b782e522 ("lib/crypto: poly1305:
Consolidate into single module").

Unlike the other hash algorithms in lib/crypto/ (e.g., SHA-512), the way
the architecture-optimized Poly1305 code is integrated results in
assembly code initializing memory, for several different architectures.
Thus, it generates false positive KMSAN warnings. These could be
suppressed with kmsan_unpoison_memory(), but it would be needed in quite
a few places. For now let's just restore the dependency on !KMSAN.

Note: this should have been caught by running poly1305_kunit with
CONFIG_KMSAN=y, which I did. However, due to an unrelated KMSAN bug
(https://lore.kernel.org/r/20251022030213.GA35717@sol/), KMSAN currently
isn't working reliably. Thus, the warning wasn't noticed until later.

Fixes: b646b782e522 ("lib/crypto: poly1305: Consolidate into single module")
Reported-by: syzbot+01fcd3...@syzkaller.appspotmail.com
Closes: https://lore.kernel.org/r/68f6a48f.050a022...@google.com/
Reported-by: Pei Xiao <xiao...@kylinos.cn>
Closes: https://lore.kernel.org/r/751b3d80293a6f599bb07770afcef24f...@kylinos.cn/
Signed-off-by: Eric Biggers <ebig...@kernel.org>
---
lib/crypto/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/crypto/Kconfig b/lib/crypto/Kconfig
index eea17e36a22be..8886055e938f2 100644
--- a/lib/crypto/Kconfig
+++ b/lib/crypto/Kconfig
@@ -95,11 +95,11 @@ config CRYPTO_LIB_POLY1305
The Poly1305 library functions. Select this if your module uses any
of the functions from <crypto/poly1305.h>.

config CRYPTO_LIB_POLY1305_ARCH
bool
- depends on CRYPTO_LIB_POLY1305 && !UML
+ depends on CRYPTO_LIB_POLY1305 && !UML && !KMSAN
default y if ARM
default y if ARM64 && KERNEL_MODE_NEON
default y if MIPS
# The PPC64 code needs to be fixed to work in softirq context.
default y if PPC64 && CPU_LITTLE_ENDIAN && VSX && BROKEN

base-commit: 552c50713f273b494ac6c77052032a49bc9255e2
--
2.51.1.dirty

Ard Biesheuvel

unread,
Oct 22, 2025, 6:14:27 AMOct 22
to Eric Biggers, linux-...@vger.kernel.org, linux-...@vger.kernel.org, Jason A . Donenfeld, Herbert Xu, Pei Xiao, Alexander Potapenko, kasa...@googlegroups.com, syzbot+01fcd3...@syzkaller.appspotmail.com
On Wed, 22 Oct 2025 at 05:37, Eric Biggers <ebig...@kernel.org> wrote:
>
> Restore the dependency of the architecture-optimized Poly1305 code on
> !KMSAN. It was dropped by commit b646b782e522 ("lib/crypto: poly1305:
> Consolidate into single module").
>
> Unlike the other hash algorithms in lib/crypto/ (e.g., SHA-512), the way
> the architecture-optimized Poly1305 code is integrated results in
> assembly code initializing memory, for several different architectures.
> Thus, it generates false positive KMSAN warnings. These could be
> suppressed with kmsan_unpoison_memory(), but it would be needed in quite
> a few places. For now let's just restore the dependency on !KMSAN.
>
> Note: this should have been caught by running poly1305_kunit with
> CONFIG_KMSAN=y, which I did. However, due to an unrelated KMSAN bug
> (https://lore.kernel.org/r/20251022030213.GA35717@sol/), KMSAN currently
> isn't working reliably. Thus, the warning wasn't noticed until later.
>
> Fixes: b646b782e522 ("lib/crypto: poly1305: Consolidate into single module")
> Reported-by: syzbot+01fcd3...@syzkaller.appspotmail.com
> Closes: https://lore.kernel.org/r/68f6a48f.050a022...@google.com/
> Reported-by: Pei Xiao <xiao...@kylinos.cn>
> Closes: https://lore.kernel.org/r/751b3d80293a6f599bb07770afcef24f...@kylinos.cn/
> Signed-off-by: Eric Biggers <ebig...@kernel.org>
> ---
> lib/crypto/Kconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>

Reviewed-by: Ard Biesheuvel <ar...@kernel.org>
Reply all
Reply to author
Forward
0 new messages