Re: [syzbot] [net?] KMSAN: uninit-value in xfrm_state_find (2)

From: Nikita Zhandarovich
Date: Wed May 15 2024 - 14:13:04 EST


> Hello,
>
> syzbot found the following issue on:
>
> HEAD commit: 3669558bdf35 Merge tag 'for-6.6-rc1-tag' of git://git.kern..
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=16656930680000
> kernel config: https://syzkaller.appspot.com/x/.config?x=754d6383bae8bc99
> dashboard link: https://syzkaller.appspot.com/bug?extid=23bbb17a7878e2b3d1d4
> compiler: Debian clang version 15.0.6, GNU ld (GNU Binutils for Debian) 2.40
>
> Unfortunately, I don't have any reproducer for this issue yet.
>
> Downloadable assets:
> disk image: https://storage.googleapis.com/syzbot-assets/f2e55d5455c8/disk-3669558b.raw.xz
> vmlinux: https://storage.googleapis.com/syzbot-assets/5a0b7323ae76/vmlinux-3669558b.xz
> kernel image: https://storage.googleapis.com/syzbot-assets/3430d935a839/bzImage-3669558b.xz
>
> IMPORTANT: if you fix the issue, please add the following tag to the commit:
> Reported-by: syzbot+23bbb17a7878e2b3d1d4@xxxxxxxxxxxxxxxxxxxxxxxxx
>
> =====================================================
> BUG: KMSAN: uninit-value in xfrm_state_find+0x17bc/0x8ce0 net/xfrm/xfrm_state.c:1160
> xfrm_state_find+0x17bc/0x8ce0 net/xfrm/xfrm_state.c:1160
> xfrm_tmpl_resolve_one net/xfrm/xfrm_policy.c:2469 [inline]
> xfrm_tmpl_resolve net/xfrm/xfrm_policy.c:2514 [inline]
> xfrm_resolve_and_create_bundle+0x80c/0x4e30 net/xfrm/xfrm_policy.c:2807
> xfrm_lookup_with_ifid+0x3f7/0x3590 net/xfrm/xfrm_policy.c:3141
> xfrm_lookup net/xfrm/xfrm_policy.c:3270 [inline]
> xfrm_lookup_route+0x63/0x2b0 net/xfrm/xfrm_policy.c:3281
> ip6_dst_lookup_flow net/ipv6/ip6_output.c:1246 [inline]
> ip6_sk_dst_lookup_flow+0x1044/0x1260 net/ipv6/ip6_output.c:1278
> udpv6_sendmsg+0x3448/0x4000 net/ipv6/udp.c:1552
> inet6_sendmsg+0x105/0x190 net/ipv6/af_inet6.c:655
> sock_sendmsg_nosec net/socket.c:730 [inline]
> sock_sendmsg net/socket.c:753 [inline]
> ____sys_sendmsg+0x9c2/0xd60 net/socket.c:2541
> ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2595
> __sys_sendmmsg+0x3c4/0x950 net/socket.c:2681
> __do_sys_sendmmsg net/socket.c:2710 [inline]
> __se_sys_sendmmsg net/socket.c:2707 [inline]
> __x64_sys_sendmmsg+0xbc/0x120 net/socket.c:2707
> do_syscall_x64 arch/x86/entry/common.c:50 [inline]
> do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80
> entry_SYSCALL_64_after_hwframe+0x63/0xcd
>
> Local variable tmp.i.i created at:
> xfrm_tmpl_resolve_one net/xfrm/xfrm_policy.c:2447 [inline]
> xfrm_tmpl_resolve net/xfrm/xfrm_policy.c:2514 [inline]
> xfrm_resolve_and_create_bundle+0x370/0x4e30 net/xfrm/xfrm_policy.c:2807
> xfrm_lookup_with_ifid+0x3f7/0x3590 net/xfrm/xfrm_policy.c:3141
>
> CPU: 0 PID: 26289 Comm: syz-executor.3 Not tainted 6.6.0-rc1-syzkaller-00033-g3669558bdf35 #0
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/04/2023
> =====================================================

Hi,

I've got a theory about the way this issue is triggered and I could
use some guidance on whether I am correct (and how to fix it).

Basically, in this case the way saddr is initialized and the way
saddr's hash is calculated are not synced (different fields of
struct xfrm_address_t are used).

xfrm_tmpl_resolve_one
...
// initialize saddr
xfrm_get_saddr
xfrm6_get_saddr
ipv6_dev_get_saddr(..., &saddr->in6); // !!!
...
xfrm_state_find
// get hash
xfrm_dst_hash
...
__xfrm6_daddr_saddr_hash
__xfrm6_addr_hash
jhash2((__force u32 *)addr->a6, 4, 0); // !!!

I am still working out the best way to come up with a quick fix for
this problem. If, in fact, I am not wrong about it.

Regards,
Nikita