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 <[email protected]>
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 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 <[email protected]>
>
> 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.