Message-ID: <tuqu4yuub5mj627dobasbiy4hbtkuvrk5gyqqf5zynli2t7xod@jxxjoworr7tp>
Date: Wed, 5 Feb 2025 10:47:03 -0500
From: "Liam R. Howlett" <Liam.Howlett@...cle.com>
To: Jann Horn <jannh@...gle.com>
Cc: syzbot <syzbot+c2e5712cbb14c95d4847@...kaller.appspotmail.com>,
        akpm@...ux-foundation.org, linux-kernel@...r.kernel.org,
        linux-mm@...ck.org, lorenzo.stoakes@...cle.com,
        syzkaller-bugs@...glegroups.com, vbabka@...e.cz
Subject: Re: [syzbot] [mm?] KCSAN: data-race in mprotect_fixup /
 try_to_migrate_one

* Jann Horn <jannh@...gle.com> [250205 10:00]:
> On Wed, Feb 5, 2025 at 12:41 PM syzbot
> <syzbot+c2e5712cbb14c95d4847@...kaller.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@...kaller.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 we need a list of vm_area_struct parts that are OK to access
without the read/write/vma lock.  It seems flags is not one of those as
it could be racy.

> 
> 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()...

...But it's okay here, for this one.  I think - maybe.  Everything is
fine.

> 
> 
> >  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@...glegroups.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

Powered by blists - more mailing lists