linux-kernel - [PATCH v2] kernel/fork.c: annotate data races for copy

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-next>] [day] [month] [year] [list]

Message-ID: <20200623041240.154294-1-chenweilong@huawei.com>
Date:   Tue, 23 Jun 2020 12:12:40 +0800
From:   Weilong Chen <chenweilong@...wei.com>
To:     <christian.brauner@...ntu.com>, <akpm@...ux-foundation.org>,
        <tglx@...utronix.de>, <lizefan@...wei.com>
CC:     <linux-kernel@...r.kernel.org>
Subject: [PATCH v2] kernel/fork.c: annotate data races for copy_process

KCSAN report there's a data race risk while using nr_threads.
But according to the comment above it:
'
        /*
         * If multiple threads are within copy_process(), then this check
         * triggers too late. This doesn't hurt, the check is only there
         * to stop root fork bombs.
         */
'
The concurrency problem is not care. And we needn't to use READ_ONCE/atomic/etc
to protect it. Meanwhile 'max_threads' is a sysctl variable which can
be modified concurrently while being read, we can use
'data_race(nr_threads >= max_threads)' to mark both of then.

BUG: KCSAN: data-race in copy_process / copy_process

write to 0xffffffff86205cf8 of 4 bytes by task 14779 on cpu 1:
  copy_process+0x2eba/0x3c40 kernel/fork.c:2273
  _do_fork+0xfe/0x7a0 kernel/fork.c:2421
  __do_sys_clone kernel/fork.c:2576 [inline]
  __se_sys_clone kernel/fork.c:2557 [inline]
  __x64_sys_clone+0x130/0x170 kernel/fork.c:2557
  do_syscall_64+0xcc/0x3a0 arch/x86/entry/common.c:294
  entry_SYSCALL_64_after_hwframe+0x44/0xa9

read to 0xffffffff86205cf8 of 4 bytes by task 6944 on cpu 0:
  copy_process+0x94d/0x3c40 kernel/fork.c:1954
  _do_fork+0xfe/0x7a0 kernel/fork.c:2421
  __do_sys_clone kernel/fork.c:2576 [inline]
  __se_sys_clone kernel/fork.c:2557 [inline]
  __x64_sys_clone+0x130/0x170 kernel/fork.c:2557
  do_syscall_64+0xcc/0x3a0 arch/x86/entry/common.c:294
  entry_SYSCALL_64_after_hwframe+0x44/0xa9
Link: https://groups.google.com/forum/#!msg/syzkaller-upstream-mo
deration/thvp7AHs5Ew/aPdYLXfYBQAJ

Reported-by: syzbot+52fced2d288f8ecd2b20@...kaller.appspotmail.com
Cc: Qian Cai <cai@....pw>
Cc: Oleg Nesterov <oleg@...hat.com>
Cc: Christian Brauner <christian.brauner@...ntu.com>
Cc: Marco Elver <elver@...gle.com>
Signed-off-by: Zefan Li <lizefan@...wei.com>
Signed-off-by: Weilong Chen <chenweilong@...wei.com>
---
 kernel/fork.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/fork.c b/kernel/fork.c
index 63c8fb2f5ca7..caa9c1f27444 100644
--- a/kernel/fork.c
+++ b/kernel/fork.c
@@ -1976,7 +1976,7 @@ static __latent_entropy struct task_struct *copy_process(
 	 * to stop root fork bombs.
 	 */
 	retval = -EAGAIN;
-	if (nr_threads >= max_threads)
+	if (data_race(nr_threads >= max_threads))
 		goto bad_fork_cleanup_count;
 
 	delayacct_tsk_init(p);	/* Must remain after dup_task_struct() */
-- 
2.17.1