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]
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ