lib/crypto/x86/poly1305.h | 2 ++ 1 file changed, 2 insertions(+)
syzbot reports uninit-value in poly1305_blocks:
BUG: KMSAN: uninit-value in poly1305_blocks+0x1a9/0x5f0 lib/crypto/x86/poly1305.h:110
poly1305_blocks+0x1a9/0x5f0 lib/crypto/x86/poly1305.h:110
poly1305_update+0x169/0x400 lib/crypto/poly1305.c:50
poly_hash+0x9f3/0x1a00 crypto/chacha20poly1305.c:168
poly_genkey+0x3b6/0x450 crypto/chacha20poly1305.c:233
chacha_encrypt crypto/chacha20poly1305.c:269 [inline]
chachapoly_encrypt+0x48a/0x5c0 crypto/chacha20poly1305.c:284
crypto_aead_encrypt+0xe2/0x160 crypto/aead.c:91
tls_do_encryption net/tls/tls_sw.c:582 [inline]
tls_push_record+0x38c7/0x5810 net/tls/tls_sw.c:819
bpf_exec_tx_verdict+0x1a0c/0x26a0 net/tls/tls_sw.c:859
tls_sw_sendmsg_locked net/tls/tls_sw.c:1138 [inline]
tls_sw_sendmsg+0x3401/0x4560 net/tls/tls_sw.c:1281
inet6_sendmsg+0x26c/0x2a0 net/ipv6/af_inet6.c:659
sock_sendmsg_nosec net/socket.c:727 [inline]
__sock_sendmsg+0x145/0x3d0 net/socket.c:742
sock_write_iter+0x3a6/0x420 net/socket.c:1195
do_iter_readv_writev+0x9e1/0xc20 fs/read_write.c:-1
vfs_writev+0x52a/0x1500 fs/read_write.c:1057
do_writev+0x1b5/0x580 fs/read_write.c:1103
__do_sys_writev fs/read_write.c:1171 [inline]
__se_sys_writev fs/read_write.c:1168 [inline]
__x64_sys_writev+0x99/0xf0 fs/read_write.c:1168
x64_sys_call+0x24b1/0x3e30 arch/x86/include/generated/asm/syscalls_64.h:21
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0xd9/0xfa0 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
in poly1305_blocks, ctx->is_base2_26 is uninit-value, ctx init in：
poly1305_init ->
poly1305_block_init
so add memset in poly1305_block_init, then use poly1305_init_x86_64 to init
by asm.
Reported-by: syzbot+01fcd39a0d90cdb0e3df@syzkaller.appspotmail.com
Tested-by: syzbot+01fcd39a0d90cdb0e3df@syzkaller.appspotmail.com
Signed-off-by: Pei Xiao <xiaopei01@kylinos.cn>
---
lib/crypto/x86/poly1305.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/lib/crypto/x86/poly1305.h b/lib/crypto/x86/poly1305.h
index ee92e3740a78..3b9f1024a18d 100644
--- a/lib/crypto/x86/poly1305.h
+++ b/lib/crypto/x86/poly1305.h
@@ -8,6 +8,7 @@
#include <linux/jump_label.h>
#include <linux/kernel.h>
#include <linux/sizes.h>
+#include <linux/string.h>
struct poly1305_arch_internal {
union {
@@ -86,6 +87,7 @@ static __ro_after_init DEFINE_STATIC_KEY_FALSE(poly1305_use_avx512);
static void poly1305_block_init(struct poly1305_block_state *state,
const u8 raw_key[POLY1305_BLOCK_SIZE])
{
+ memset(state, 0, sizeof(struct poly1305_block_state));
poly1305_init_x86_64(state, raw_key);
}
--
2.25.1
On Tue, Oct 21, 2025 at 02:01:20PM +0800, Pei Xiao wrote: > syzbot reports uninit-value in poly1305_blocks: > > BUG: KMSAN: uninit-value in poly1305_blocks+0x1a9/0x5f0 lib/crypto/x86/poly1305.h:110 > poly1305_blocks+0x1a9/0x5f0 lib/crypto/x86/poly1305.h:110 > poly1305_update+0x169/0x400 lib/crypto/poly1305.c:50 > poly_hash+0x9f3/0x1a00 crypto/chacha20poly1305.c:168 > poly_genkey+0x3b6/0x450 crypto/chacha20poly1305.c:233 > chacha_encrypt crypto/chacha20poly1305.c:269 [inline] > chachapoly_encrypt+0x48a/0x5c0 crypto/chacha20poly1305.c:284 > crypto_aead_encrypt+0xe2/0x160 crypto/aead.c:91 > tls_do_encryption net/tls/tls_sw.c:582 [inline] > tls_push_record+0x38c7/0x5810 net/tls/tls_sw.c:819 > bpf_exec_tx_verdict+0x1a0c/0x26a0 net/tls/tls_sw.c:859 > tls_sw_sendmsg_locked net/tls/tls_sw.c:1138 [inline] > tls_sw_sendmsg+0x3401/0x4560 net/tls/tls_sw.c:1281 > inet6_sendmsg+0x26c/0x2a0 net/ipv6/af_inet6.c:659 > sock_sendmsg_nosec net/socket.c:727 [inline] > __sock_sendmsg+0x145/0x3d0 net/socket.c:742 > sock_write_iter+0x3a6/0x420 net/socket.c:1195 > do_iter_readv_writev+0x9e1/0xc20 fs/read_write.c:-1 > vfs_writev+0x52a/0x1500 fs/read_write.c:1057 > do_writev+0x1b5/0x580 fs/read_write.c:1103 > __do_sys_writev fs/read_write.c:1171 [inline] > __se_sys_writev fs/read_write.c:1168 [inline] > __x64_sys_writev+0x99/0xf0 fs/read_write.c:1168 > x64_sys_call+0x24b1/0x3e30 arch/x86/include/generated/asm/syscalls_64.h:21 > do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] > do_syscall_64+0xd9/0xfa0 arch/x86/entry/syscall_64.c:94 > entry_SYSCALL_64_after_hwframe+0x77/0x7f > > in poly1305_blocks, ctx->is_base2_26 is uninit-value, ctx init in： > poly1305_init -> > poly1305_block_init > > so add memset in poly1305_block_init, then use poly1305_init_x86_64 to init > by asm. > > Reported-by: syzbot+01fcd39a0d90cdb0e3df@syzkaller.appspotmail.com > Tested-by: syzbot+01fcd39a0d90cdb0e3df@syzkaller.appspotmail.com > Signed-off-by: Pei Xiao <xiaopei01@kylinos.cn> > --- Thanks for the bug report. It will first need to be confirmed that this is actually an issue in lib/crypto/ rather than the calling code, and if so, why poly1305_kunit doesn't catch it (even when run on an KMSAN enabled kernel, which I've done). And which commit it fixes. I'm guessing it's most likely a KMSAN false positive that was exposed by commit b646b782e522 dropping the dependency of the architecture-optimized Poly1305 code on !KMSAN. KMSAN doesn't know about memory initialization done by assembly code. But I'll double check this, if you don't get around to it first. The hash algorithms generally don't need a dependency on !KMSAN, as their assembly code doesn't initialize memory. It looks like the Poly1305 code is an exception to that though, and I missed it. If so, the proper solution (IMO) is to use kmsan_unpoison_memory() right after the assembly function that initializes the memory is called. See sha256_finup_2x_arch() for an example of that. Note that more than one architecture may need this. If it ends up being too inconvenient, we can make the architecture-optimized Poly1305 code depend on !KMSAN again. But preserving KMSAN coverage is preferable. - Eric
在 2025/10/21 14:15, Eric Biggers 写道: > On Tue, Oct 21, 2025 at 02:01:20PM +0800, Pei Xiao wrote: >> syzbot reports uninit-value in poly1305_blocks: >> >> BUG: KMSAN: uninit-value in poly1305_blocks+0x1a9/0x5f0 lib/crypto/x86/poly1305.h:110 >> poly1305_blocks+0x1a9/0x5f0 lib/crypto/x86/poly1305.h:110 >> poly1305_update+0x169/0x400 lib/crypto/poly1305.c:50 >> poly_hash+0x9f3/0x1a00 crypto/chacha20poly1305.c:168 >> poly_genkey+0x3b6/0x450 crypto/chacha20poly1305.c:233 >> chacha_encrypt crypto/chacha20poly1305.c:269 [inline] >> chachapoly_encrypt+0x48a/0x5c0 crypto/chacha20poly1305.c:284 >> crypto_aead_encrypt+0xe2/0x160 crypto/aead.c:91 >> tls_do_encryption net/tls/tls_sw.c:582 [inline] >> tls_push_record+0x38c7/0x5810 net/tls/tls_sw.c:819 >> bpf_exec_tx_verdict+0x1a0c/0x26a0 net/tls/tls_sw.c:859 >> tls_sw_sendmsg_locked net/tls/tls_sw.c:1138 [inline] >> tls_sw_sendmsg+0x3401/0x4560 net/tls/tls_sw.c:1281 >> inet6_sendmsg+0x26c/0x2a0 net/ipv6/af_inet6.c:659 >> sock_sendmsg_nosec net/socket.c:727 [inline] >> __sock_sendmsg+0x145/0x3d0 net/socket.c:742 >> sock_write_iter+0x3a6/0x420 net/socket.c:1195 >> do_iter_readv_writev+0x9e1/0xc20 fs/read_write.c:-1 >> vfs_writev+0x52a/0x1500 fs/read_write.c:1057 >> do_writev+0x1b5/0x580 fs/read_write.c:1103 >> __do_sys_writev fs/read_write.c:1171 [inline] >> __se_sys_writev fs/read_write.c:1168 [inline] >> __x64_sys_writev+0x99/0xf0 fs/read_write.c:1168 >> x64_sys_call+0x24b1/0x3e30 arch/x86/include/generated/asm/syscalls_64.h:21 >> do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] >> do_syscall_64+0xd9/0xfa0 arch/x86/entry/syscall_64.c:94 >> entry_SYSCALL_64_after_hwframe+0x77/0x7f >> >> in poly1305_blocks, ctx->is_base2_26 is uninit-value, ctx init in： >> poly1305_init -> >> poly1305_block_init >> >> so add memset in poly1305_block_init, then use poly1305_init_x86_64 to init >> by asm. >> >> Reported-by: syzbot+01fcd39a0d90cdb0e3df@syzkaller.appspotmail.com >> Tested-by: syzbot+01fcd39a0d90cdb0e3df@syzkaller.appspotmail.com >> Signed-off-by: Pei Xiao <xiaopei01@kylinos.cn> >> --- hi Eric, thanks for your responce. > Thanks for the bug report. It will first need to be confirmed that this > is actually an issue in lib/crypto/ rather than the calling code, and if > so, why poly1305_kunit doesn't catch it (even when run on an KMSAN > enabled kernel, which I've done). And which commit it fixes. I'm > guessing it's most likely a KMSAN false positive that was exposed by > commit b646b782e522 dropping the dependency of the > architecture-optimized Poly1305 code on !KMSAN. KMSAN doesn't know > about memory initialization done by assembly code. But I'll double > check this, if you don't get around to it first. > > The hash algorithms generally don't need a dependency on !KMSAN, as > their assembly code doesn't initialize memory. It looks like the > Poly1305 code is an exception to that though, and I missed it. If so, > the proper solution (IMO) is to use kmsan_unpoison_memory() right after > the assembly function that initializes the memory is called. See > sha256_finup_2x_arch() for an example of that. Note that more than one > architecture may need this. --- a/lib/crypto/poly1305.c +++ b/lib/crypto/poly1305.c @@ -13,6 +13,7 @@ #include <linux/module.h> #include <linux/string.h> #include <linux/unaligned.h> +#include <linux/kmsan.h> #ifdef CONFIG_CRYPTO_LIB_POLY1305_ARCH #include "poly1305.h" /* $(SRCARCH)/poly1305.h */ @@ -31,6 +32,7 @@ void poly1305_init(struct poly1305_desc_ctx *desc, desc->s[3] = get_unaligned_le32(key + 28); desc->buflen = 0; poly1305_block_init(&desc->state, key); + kmsan_unpoison_memory(desc, sizeof(struct poly1305_desc_ctx)); } EXPORT_SYMBOL(poly1305_init) how about this ? > If it ends up being too inconvenient, we > can make the architecture-optimized Poly1305 code depend on !KMSAN > again. But preserving KMSAN coverage is preferable. > > - Eric thanks!
On Tue, Oct 21, 2025 at 04:40:47PM +0800, Pei Xiao wrote: > > 在 2025/10/21 14:15, Eric Biggers 写道: > > On Tue, Oct 21, 2025 at 02:01:20PM +0800, Pei Xiao wrote: > >> syzbot reports uninit-value in poly1305_blocks: > >> > >> BUG: KMSAN: uninit-value in poly1305_blocks+0x1a9/0x5f0 lib/crypto/x86/poly1305.h:110 > >> poly1305_blocks+0x1a9/0x5f0 lib/crypto/x86/poly1305.h:110 > >> poly1305_update+0x169/0x400 lib/crypto/poly1305.c:50 > >> poly_hash+0x9f3/0x1a00 crypto/chacha20poly1305.c:168 > >> poly_genkey+0x3b6/0x450 crypto/chacha20poly1305.c:233 > >> chacha_encrypt crypto/chacha20poly1305.c:269 [inline] > >> chachapoly_encrypt+0x48a/0x5c0 crypto/chacha20poly1305.c:284 > >> crypto_aead_encrypt+0xe2/0x160 crypto/aead.c:91 > >> tls_do_encryption net/tls/tls_sw.c:582 [inline] > >> tls_push_record+0x38c7/0x5810 net/tls/tls_sw.c:819 > >> bpf_exec_tx_verdict+0x1a0c/0x26a0 net/tls/tls_sw.c:859 > >> tls_sw_sendmsg_locked net/tls/tls_sw.c:1138 [inline] > >> tls_sw_sendmsg+0x3401/0x4560 net/tls/tls_sw.c:1281 > >> inet6_sendmsg+0x26c/0x2a0 net/ipv6/af_inet6.c:659 > >> sock_sendmsg_nosec net/socket.c:727 [inline] > >> __sock_sendmsg+0x145/0x3d0 net/socket.c:742 > >> sock_write_iter+0x3a6/0x420 net/socket.c:1195 > >> do_iter_readv_writev+0x9e1/0xc20 fs/read_write.c:-1 > >> vfs_writev+0x52a/0x1500 fs/read_write.c:1057 > >> do_writev+0x1b5/0x580 fs/read_write.c:1103 > >> __do_sys_writev fs/read_write.c:1171 [inline] > >> __se_sys_writev fs/read_write.c:1168 [inline] > >> __x64_sys_writev+0x99/0xf0 fs/read_write.c:1168 > >> x64_sys_call+0x24b1/0x3e30 arch/x86/include/generated/asm/syscalls_64.h:21 > >> do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] > >> do_syscall_64+0xd9/0xfa0 arch/x86/entry/syscall_64.c:94 > >> entry_SYSCALL_64_after_hwframe+0x77/0x7f > >> > >> in poly1305_blocks, ctx->is_base2_26 is uninit-value, ctx init in： > >> poly1305_init -> > >> poly1305_block_init > >> > >> so add memset in poly1305_block_init, then use poly1305_init_x86_64 to init > >> by asm. > >> > >> Reported-by: syzbot+01fcd39a0d90cdb0e3df@syzkaller.appspotmail.com > >> Tested-by: syzbot+01fcd39a0d90cdb0e3df@syzkaller.appspotmail.com > >> Signed-off-by: Pei Xiao <xiaopei01@kylinos.cn> > >> --- > > hi Eric, > > thanks for your responce. > > > Thanks for the bug report. It will first need to be confirmed that this > > is actually an issue in lib/crypto/ rather than the calling code, and if > > so, why poly1305_kunit doesn't catch it (even when run on an KMSAN > > enabled kernel, which I've done). And which commit it fixes. I'm > > guessing it's most likely a KMSAN false positive that was exposed by > > commit b646b782e522 dropping the dependency of the > > architecture-optimized Poly1305 code on !KMSAN. KMSAN doesn't know > > about memory initialization done by assembly code. But I'll double > > check this, if you don't get around to it first. > > > > The hash algorithms generally don't need a dependency on !KMSAN, as > > their assembly code doesn't initialize memory. It looks like the > > Poly1305 code is an exception to that though, and I missed it. If so, > > the proper solution (IMO) is to use kmsan_unpoison_memory() right after > > the assembly function that initializes the memory is called. See > > sha256_finup_2x_arch() for an example of that. Note that more than one > > architecture may need this. > > --- a/lib/crypto/poly1305.c > +++ b/lib/crypto/poly1305.c > @@ -13,6 +13,7 @@ > #include <linux/module.h> > #include <linux/string.h> > #include <linux/unaligned.h> > +#include <linux/kmsan.h> > > #ifdef CONFIG_CRYPTO_LIB_POLY1305_ARCH > #include "poly1305.h" /* $(SRCARCH)/poly1305.h */ > @@ -31,6 +32,7 @@ void poly1305_init(struct poly1305_desc_ctx *desc, > desc->s[3] = get_unaligned_le32(key + 28); > desc->buflen = 0; > poly1305_block_init(&desc->state, key); > + kmsan_unpoison_memory(desc, sizeof(struct poly1305_desc_ctx)); > } > EXPORT_SYMBOL(poly1305_init) > > how about this ? > It should only be after the specific assembly functions that need it. I haven't had a chance to look into this since your first email, but again, I would like to confirm that (a) this is actually the issue, (b) before we suppress the warnings, that all the assembly functions actually initialize all the memory they're supposed to, and (c) which places in the Poly1305 code actually need this. If (c) ends up being too many places (I think it might), we probably should just make CRYPTO_LIB_POLY1305_ARCH depend on !KMSAN again. - Eric
在 2025/10/21 14:15, Eric Biggers 写道: > On Tue, Oct 21, 2025 at 02:01:20PM +0800, Pei Xiao wrote: >> syzbot reports uninit-value in poly1305_blocks: >> >> BUG: KMSAN: uninit-value in poly1305_blocks+0x1a9/0x5f0 lib/crypto/x86/poly1305.h:110 >> poly1305_blocks+0x1a9/0x5f0 lib/crypto/x86/poly1305.h:110 >> poly1305_update+0x169/0x400 lib/crypto/poly1305.c:50 >> poly_hash+0x9f3/0x1a00 crypto/chacha20poly1305.c:168 >> poly_genkey+0x3b6/0x450 crypto/chacha20poly1305.c:233 >> chacha_encrypt crypto/chacha20poly1305.c:269 [inline] >> chachapoly_encrypt+0x48a/0x5c0 crypto/chacha20poly1305.c:284 >> crypto_aead_encrypt+0xe2/0x160 crypto/aead.c:91 >> tls_do_encryption net/tls/tls_sw.c:582 [inline] >> tls_push_record+0x38c7/0x5810 net/tls/tls_sw.c:819 >> bpf_exec_tx_verdict+0x1a0c/0x26a0 net/tls/tls_sw.c:859 >> tls_sw_sendmsg_locked net/tls/tls_sw.c:1138 [inline] >> tls_sw_sendmsg+0x3401/0x4560 net/tls/tls_sw.c:1281 >> inet6_sendmsg+0x26c/0x2a0 net/ipv6/af_inet6.c:659 >> sock_sendmsg_nosec net/socket.c:727 [inline] >> __sock_sendmsg+0x145/0x3d0 net/socket.c:742 >> sock_write_iter+0x3a6/0x420 net/socket.c:1195 >> do_iter_readv_writev+0x9e1/0xc20 fs/read_write.c:-1 >> vfs_writev+0x52a/0x1500 fs/read_write.c:1057 >> do_writev+0x1b5/0x580 fs/read_write.c:1103 >> __do_sys_writev fs/read_write.c:1171 [inline] >> __se_sys_writev fs/read_write.c:1168 [inline] >> __x64_sys_writev+0x99/0xf0 fs/read_write.c:1168 >> x64_sys_call+0x24b1/0x3e30 arch/x86/include/generated/asm/syscalls_64.h:21 >> do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] >> do_syscall_64+0xd9/0xfa0 arch/x86/entry/syscall_64.c:94 >> entry_SYSCALL_64_after_hwframe+0x77/0x7f >> >> in poly1305_blocks, ctx->is_base2_26 is uninit-value, ctx init in： >> poly1305_init -> >> poly1305_block_init >> >> so add memset in poly1305_block_init, then use poly1305_init_x86_64 to init >> by asm. >> >> Reported-by: syzbot+01fcd39a0d90cdb0e3df@syzkaller.appspotmail.com >> Tested-by: syzbot+01fcd39a0d90cdb0e3df@syzkaller.appspotmail.com >> Signed-off-by: Pei Xiao <xiaopei01@kylinos.cn> >> --- > Thanks for the bug report. It will first need to be confirmed that this > is actually an issue in lib/crypto/ rather than the calling code, and if > so, why poly1305_kunit doesn't catch it (even when run on an KMSAN > enabled kernel, which I've done). Is this related to the compiler type? I see it was compiled with Debian clang version 20.1.8 > And which commit it fixes. I'm > guessing it's most likely a KMSAN false positive that was exposed by > commit b646b782e522 dropping the dependency of the > architecture-optimized Poly1305 code on !KMSAN. KMSAN doesn't know > about memory initialization done by assembly code. But I'll double > check this, if you don't get around to it first. > > The hash algorithms generally don't need a dependency on !KMSAN, as > their assembly code doesn't initialize memory. It looks like the > Poly1305 code is an exception to that though, and I missed it. If so, > the proper solution (IMO) is to use kmsan_unpoison_memory() right after > the assembly function that initializes the memory is called. See > sha256_finup_2x_arch() for an example of that. Note that more than one > architecture may need this. So may I send a patch by use kmsan_unpoison_memory(out1, SHA256_DIGEST_SIZE); ? > If it ends up being too inconvenient, we > can make the architecture-optimized Poly1305 code depend on !KMSAN > again. But preserving KMSAN coverage is preferable. > > - Eric thanks！ Pei.
© 2016 - 2026 Red Hat, Inc.