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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20251021061511.GA2385@sol>
Date: Mon, 20 Oct 2025 23:15:11 -0700
From: Eric Biggers <ebiggers@...nel.org>
To: Pei Xiao <xiaopei01@...inos.cn>
Cc: Jason@...c4.com, ardb@...nel.org, ubizjak@...il.com,
	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 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>
> ---

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