linux-kernel - Re: [PATCH] lib/crypto: poly1305: fix uninit-value in poly1305

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20251021151455.GB1644@quark>
Date: Tue, 21 Oct 2025 08:14:55 -0700
From: Eric Biggers <ebiggers@...nel.org>
To: Pei Xiao <xiaopei01@...inos.cn>
Cc: linux-crypto@...r.kernel.org, linux-kernel@...r.kernel.org,
	syzbot+01fcd39a0d90cdb0e3df@...kaller.appspotmail.com
Subject: Re: [PATCH] lib/crypto: poly1305: fix uninit-value in poly1305_blocks

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@...kaller.appspotmail.com
> >> Tested-by: syzbot+01fcd39a0d90cdb0e3df@...kaller.appspotmail.com
> >> Signed-off-by: Pei Xiao <xiaopei01@...inos.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