Re: KCSAN: data-race in task_mem / unmap_region

[Christian Brauner <brauner@kernel.org>]

On Tue, Jan 11, 2022 at 09:56:59PM +0800, Kaia Yadira wrote:
> Hello,
> 
> When using Syzkaller to fuzz the latest Linux kernel, the following
> crash was triggered.
> 
> HEAD commit: a7904a538933 Linux 5.16-rc6
> git tree: upstream
> console output: KCSAN: data-race in task_mem / unmap_region
> kernel config: https://paste.ubuntu.com/p/QB39MJKWKb/plain/
> Syzlang reproducer: https://paste.ubuntu.com/p/q2DVwVh6hr/plain/
> 
> If you fix this issue, please add the following tag to the commit:
> 
> Reported-by: Hypericum <hypericumperforatum4444@gmail.com>
> 
> I think fs/proc/task_mmu.c visits the variable mm without locking and
> another mmap visits mm->hiwater_vm resulting in a data race.
> 
> reproducer log: https://paste.ubuntu.com/p/Sp6RDWKDfy/plain/
> reproducer report:
> ==================================================================
> BUG: KCSAN: data-race in task_mem / unmap_region
> 
> write to 0xffff8881095008b0 of 8 bytes by task 3712 on cpu 4:
>  update_hiwater_rss include/linux/mm.h:2102 [inline]
>  unmap_region+0x12b/0x1e0 mm/mmap.c:2648
>  __do_munmap+0xe6e/0x12b0 mm/mmap.c:2883
>  __vm_munmap mm/mmap.c:2906 [inline]
>  __do_sys_munmap+0x9f/0x160 mm/mmap.c:2932
>  __se_sys_munmap mm/mmap.c:2928 [inline]
>  __x64_sys_munmap+0x2d/0x40 mm/mmap.c:2928
>  do_syscall_x64 arch/x86/entry/common.c:50 [inline]
>  do_syscall_64+0x44/0xd0 arch/x86/entry/common.c:80
>  entry_SYSCALL_64_after_hwframe+0x44/0xae
> 
> read to 0xffff8881095008b0 of 8 bytes by task 1512 on cpu 7:
>  task_mem+0xfb/0x3d0 fs/proc/task_mmu.c:50
>  proc_pid_status+0x890/0x14d0 fs/proc/array.c:438
>  proc_single_show+0x84/0x100 fs/proc/base.c:778
>  seq_read_iter+0x2e3/0x930 fs/seq_file.c:230
>  seq_read+0x234/0x280 fs/seq_file.c:162
>  vfs_read+0x1e6/0x730 fs/read_write.c:479
>  ksys_read+0xd9/0x190 fs/read_write.c:619
>  __do_sys_read fs/read_write.c:629 [inline]
>  __se_sys_read fs/read_write.c:627 [inline]
>  __x64_sys_read+0x3e/0x50 fs/read_write.c:627
>  do_syscall_x64 arch/x86/entry/common.c:50 [inline]
>  do_syscall_64+0x44/0xd0 arch/x86/entry/common.c:80
>  entry_SYSCALL_64_after_hwframe+0x44/0xae
> 
> value changed: 0x000000000000065b -> 0x0000000000000662
> 
> Reported by Kernel Concurrency Sanitizer on:
> CPU: 7 PID: 1512 Comm: systemd-journal Not tainted 5.16.0-rc8+ #11
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
> 1.13.0-1ubuntu1.1 04/01/2014
> ==================================================================

On Tue, Jan 11, 2022 at 01:38:28PM +0000, Matthew Wilcox wrote:
> On Tue, Jan 11, 2022 at 10:38:02AM +0100, Aleksandr Nogikh wrote:
> > Hi Matthew,
> > 
> > That report was not sent by syzbot, rather by someone else. syzbot tries to
> > be much more careful with the INFO: reports.
> > 
> > During the past couple of weeks there has been some outburst of similar
> > reports from various senders - this is the third different sender I see,
> > probably there are also much more.
> 
> Right.  Perhaps syzcaller could *not* call sched_setscheduler() by
> default.  Require an --i-know-what-im-doing-and-wont-submit-bogus-reports
> flag to be specified by the user in order to call that syscall?

Yeah, can we stop reports from this particular non-"official" syzkaller
instance, please? We've received at least 3 or 4 of those just today and
frankly the reports generated here are not very useful in debugging
these issues; especially when contrasted with syzkaller "proper".
Frankly, it's pretty difficult to even tell they're legitimate. At first
I thought this is spam.

Honestly, I think we need to require that static analyzer, fuzzers and
so on need to register themselves with kernel.org or some other way
before allowing them to spam mailing lists.