Re: [syzbot] [mm?] KCSAN: data-race in mprotect_fixup / try_to_migrate_one

[Jann Horn <jannh@google.com>]

On Wed, Feb 5, 2025 at 12:41 PM syzbot
<syzbot+c2e5712cbb14c95d4847@syzkaller.appspotmail.com> wrote:
> syzbot found the following issue on:
>
> HEAD commit:    d009de7d5428 Merge tag 'livepatching-for-6.14-rc2' of git:..
> git tree:       upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=12b678a4580000
> kernel config:  https://syzkaller.appspot.com/x/.config?x=9e757e3762bd630b
> dashboard link: https://syzkaller.appspot.com/bug?extid=c2e5712cbb14c95d4847
> 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/9235000a1b88/disk-d009de7d.raw.xz
> vmlinux: https://storage.googleapis.com/syzbot-assets/098ef82f8ab3/vmlinux-d009de7d.xz
> kernel image: https://storage.googleapis.com/syzbot-assets/4f51f5eb5782/bzImage-d009de7d.xz
>
> IMPORTANT: if you fix the issue, please add the following tag to the commit:
> Reported-by: syzbot+c2e5712cbb14c95d4847@syzkaller.appspotmail.com
>
> ==================================================================
> BUG: KCSAN: data-race in mprotect_fixup / try_to_migrate_one
>
> write to 0xffff888114b41700 of 8 bytes by task 6432 on cpu 1:
>  vm_flags_init include/linux/mm.h:875 [inline]
>  vm_flags_reset include/linux/mm.h:887 [inline]
>  mprotect_fixup+0x419/0x5e0 mm/mprotect.c:679
>  do_mprotect_pkey+0x6cc/0x9a0 mm/mprotect.c:840

This is one side changing the VMA flags under the mmap lock in write mode...

>  __do_sys_mprotect mm/mprotect.c:861 [inline]
>  __se_sys_mprotect mm/mprotect.c:858 [inline]
>  __x64_sys_mprotect+0x48/0x60 mm/mprotect.c:858
>  x64_sys_call+0x2770/0x2dc0 arch/x86/include/generated/asm/syscalls_64.h:11
>  do_syscall_x64 arch/x86/entry/common.c:52 [inline]
>  do_syscall_64+0xc9/0x1c0 arch/x86/entry/common.c:83
>  entry_SYSCALL_64_after_hwframe+0x77/0x7f
>
> read to 0xffff888114b41700 of 8 bytes by task 6418 on cpu 0:
>  try_to_migrate_one+0xb5a/0x12e0 mm/rmap.c:2321
>  rmap_walk_anon+0x28f/0x440 mm/rmap.c:2646

... while the other side comes through the rmap, which does not
involve the mmap lock. Yes, that does not have any mutual locking by
design, I think.

The comments in the VMA flags code incorrectly assume that no
concurrency is possible here; and I think the comment in
mprotect_fixup() about protection by the mmap_lock has also been kinda
wrong since the beginning of git history.

The VM_LOCKED check in the migration code was added by Hugh in commit
b74355078b655, but that's just one example syzbot stumbled over; we
have similar racy vm_flags reads through the rmap on other paths like:

unmap_mapping_range_tree -> unmap_mapping_range_vma ->
zap_page_range_single -> unmap_single_vma -> unmap_page_range -> ...
-> zap_pte_range -> zap_present_ptes -> vm_normal_page

I think the right fix might just be to make sure that we use
WRITE_ONCE() for these vm_flags updates, and READ_ONCE() around
->vm_flags reads that can happen in rmap walk paths, though we should
think about the consequences of concurrently changing flags in every
place that gets a READ_ONCE()...


>  try_to_migrate+0x11f/0x150
>  migrate_folio_unmap mm/migrate.c:1320 [inline]
>  migrate_pages_batch+0x786/0x1930 mm/migrate.c:1866
>  migrate_pages_sync mm/migrate.c:1989 [inline]
>  migrate_pages+0xf02/0x1840 mm/migrate.c:2098
>  do_mbind mm/mempolicy.c:1394 [inline]
>  kernel_mbind mm/mempolicy.c:1537 [inline]
>  __do_sys_mbind mm/mempolicy.c:1611 [inline]
>  __se_sys_mbind+0xfd1/0x11c0 mm/mempolicy.c:1607
>  __x64_sys_mbind+0x78/0x90 mm/mempolicy.c:1607
>  x64_sys_call+0x2662/0x2dc0 arch/x86/include/generated/asm/syscalls_64.h:238
>  do_syscall_x64 arch/x86/entry/common.c:52 [inline]
>  do_syscall_64+0xc9/0x1c0 arch/x86/entry/common.c:83
>  entry_SYSCALL_64_after_hwframe+0x77/0x7f
>
> value changed: 0x0000000000102077 -> 0x0000000000102071
>
> Reported by Kernel Concurrency Sanitizer on:
> CPU: 0 UID: 0 PID: 6418 Comm: syz.0.1339 Not tainted 6.14.0-rc1-syzkaller-00026-gd009de7d5428 #0
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 12/27/2024
> ==================================================================
>
>
> ---
> This report is generated by a bot. It may contain errors.
> See https://goo.gl/tpsmEJ for more information about syzbot.
> syzbot engineers can be reached at syzkaller@googlegroups.com.
>
> syzbot will keep track of this issue. See:
> https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
>
> If the report is already addressed, let syzbot know by replying with:
> #syz fix: exact-commit-title
>
> If you want to overwrite report's subsystems, reply with:
> #syz set subsystems: new-subsystem
> (See the list of subsystem names on the web dashboard)
>
> If the report is a duplicate of another one, reply with:
> #syz dup: exact-subject-of-another-report
>
> If you want to undo deduplication, reply with:
> #syz undup