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
| ||
|
Message-ID: <20240515181239.4127-1-n.zhandarovich@fintech.ru> Date: Wed, 15 May 2024 11:12:39 -0700 From: Nikita Zhandarovich <n.zhandarovich@...tech.ru> To: syzbot <syzbot+23bbb17a7878e2b3d1d4@...kaller.appspotmail.com>, <davem@...emloft.net>, <edumazet@...gle.com>, <herbert@...dor.apana.org.au>, <kuba@...nel.org>, <linux-kernel@...r.kernel.org>, <netdev@...r.kernel.org>, <pabeni@...hat.com>, <steffen.klassert@...unet.com>, <syzkaller-bugs@...glegroups.com> CC: Nikita Zhandarovich <n.zhandarovich@...tech.ru> Subject: Re: [syzbot] [net?] KMSAN: uninit-value in xfrm_state_find (2) > 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@...kaller.appspotmail.com > > ===================================================== > 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
Powered by blists - more mailing lists