* Jann Horn <jannh@xxxxxxxxxx> [250205 10:00]: > On Wed, Feb 5, 2025 at 12:41 PM syzbot > <syzbot+c2e5712cbb14c95d4847@xxxxxxxxxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxxxxxx > > > > ================================================================== > > 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@xxxxxxxxxxxxxxxx. > > > > 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
