netdev - Re: [syzbot] [net?] [v9fs?] KCSAN: data-race in p9_fd_create / p9_fd

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]

Date: Tue, 29 Aug 2023 19:57:24 +0900
From: Dominique Martinet <asmadeus@...ewreck.org>
To: syzbot <syzbot+e441aeeb422763cc5511@...kaller.appspotmail.com>
Cc: davem@...emloft.net, edumazet@...gle.com, ericvh@...nel.org,
	kuba@...nel.org, linux-fsdevel@...r.kernel.org,
	linux-kernel@...r.kernel.org, linux_oss@...debyte.com,
	lucho@...kov.net, netdev@...r.kernel.org, pabeni@...hat.com,
	syzkaller-bugs@...glegroups.com, v9fs@...ts.linux.dev
Subject: Re: [syzbot] [net?] [v9fs?] KCSAN: data-race in p9_fd_create /
 p9_fd_create (2)

syzbot wrote on Tue, Aug 29, 2023 at 02:39:53AM -0700:
> ==================================================================
> BUG: KCSAN: data-race in p9_fd_create / p9_fd_create
> 
> read-write to 0xffff888130fb3d48 of 4 bytes by task 15599 on cpu 0:
>  p9_fd_open net/9p/trans_fd.c:842 [inline]
>  p9_fd_create+0x210/0x250 net/9p/trans_fd.c:1092
>  p9_client_create+0x595/0xa70 net/9p/client.c:1010
>  v9fs_session_init+0xf9/0xd90 fs/9p/v9fs.c:410
>  v9fs_mount+0x69/0x630 fs/9p/vfs_super.c:123
>  legacy_get_tree+0x74/0xd0 fs/fs_context.c:611
>  vfs_get_tree+0x51/0x190 fs/super.c:1519
>  do_new_mount+0x203/0x660 fs/namespace.c:3335
>  path_mount+0x496/0xb30 fs/namespace.c:3662
>  do_mount fs/namespace.c:3675 [inline]
>  __do_sys_mount fs/namespace.c:3884 [inline]
>  __se_sys_mount+0x27f/0x2d0 fs/namespace.c:3861
>  __x64_sys_mount+0x67/0x80 fs/namespace.c:3861
>  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
> 
> read-write to 0xffff888130fb3d48 of 4 bytes by task 15563 on cpu 1:
>  p9_fd_open net/9p/trans_fd.c:842 [inline]
>  p9_fd_create+0x210/0x250 net/9p/trans_fd.c:1092
>  p9_client_create+0x595/0xa70 net/9p/client.c:1010
>  v9fs_session_init+0xf9/0xd90 fs/9p/v9fs.c:410
>  v9fs_mount+0x69/0x630 fs/9p/vfs_super.c:123
>  legacy_get_tree+0x74/0xd0 fs/fs_context.c:611
>  vfs_get_tree+0x51/0x190 fs/super.c:1519
>  do_new_mount+0x203/0x660 fs/namespace.c:3335
>  path_mount+0x496/0xb30 fs/namespace.c:3662
>  do_mount fs/namespace.c:3675 [inline]
>  __do_sys_mount fs/namespace.c:3884 [inline]
>  __se_sys_mount+0x27f/0x2d0 fs/namespace.c:3861
>  __x64_sys_mount+0x67/0x80 fs/namespace.c:3861
>  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
> 
> value changed: 0x00008002 -> 0x00008802

Yes well that doesn't seem too hard to hit, both threads are just
setting O_NONBLOCK to the same fd in parallel (0x800 is 04000,
O_NONBLOCK)

I'm not quite sure why that'd be a problem; and I'm also pretty sure
that wouldn't work anyway (9p has no muxing or anything that'd allow
sharing the same fd between multiple mounts)

Can this be flagged "don't care" ?

-- 
Dominique Martinet | Asmadeus