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

[Pei Xiao <xiaopei01@kylinos.cn>]

在 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.