On Wed, Aug 28, 2024 at 02:37:04PM GMT, Xingyu Li wrote: > Hi, > > We found a bug in Linux 6.10 using syzkaller. It is possibly a logic bug. These lines are actually a bit offset for 6.10.. > The reprodcuer is > https://gist.github.com/freexxxyyy/5f0c95e95e1bc0fb681e504114b61de8 Again, this doesn't repro for me. And the call stack suggests this doesn't occur in the repro but on a process exit. > > The bug report is: > > WARNING: CPU: 0 PID: 8053 at include/linux/rwsem.h:203 This is: lockdep_assert_held_write(sem); So presumably lockdep is on here (be good to get .config, full dmesg). > mmap_assert_write_locked include/linux/mmap_lock.h:70 [inline] This is: rwsem_assert_held_write(&mm->mmap_lock); > WARNING: CPU: 0 PID: 8053 at include/linux/rwsem.h:203 > __is_vma_write_locked include/linux/mm.h:714 [inline] Should be 715? Guess inlined, but problematic line seems to be: mmap_assert_write_locked(vma->vm_mm); > WARNING: CPU: 0 PID: 8053 at include/linux/rwsem.h:203 vma_start_write > include/linux/mm.h:733 [inline] > WARNING: CPU: 0 PID: 8053 at include/linux/rwsem.h:203 > free_pgtables+0x4df/0xbb0 mm/memory.c:403 > Modules linked in: > CPU: 0 PID: 8053 Comm: syz-executor107 Not tainted 6.10.0 #13 > Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 > RIP: 0010:rwsem_assert_held_write include/linux/rwsem.h:203 [inline] > RIP: 0010:mmap_assert_write_locked include/linux/mmap_lock.h:70 [inline] > RIP: 0010:__is_vma_write_locked include/linux/mm.h:714 [inline] > RIP: 0010:vma_start_write include/linux/mm.h:733 [inline] > RIP: 0010:free_pgtables+0x4df/0xbb0 mm/memory.c:403 > Code: 04 00 4d 85 e4 0f 84 86 03 00 00 e8 3b 46 b6 ff 4d 89 ee 4d 89 > e5 49 bc 00 00 00 00 00 fc ff df e9 86 fd ff ff e8 21 46 b6 ff <0f> 0b > e9 b8 fe ff ff 48 c7 c1 6c 91 24 8f 80 e1 07 80 c1 03 38 c1 > RSP: 0018:ffffc9000ac7f748 EFLAGS: 00010293 > RAX: ffffffff81db0b3f RBX: ffff88801d8cbe98 RCX: ffff888021fa1e00 > RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 > RBP: 0000000000000000 R08: ffffffff81db09ea R09: ffffffff8aed5df0 > R10: 0000000000000004 R11: ffff888021fa1e00 R12: ffff88802ce66ba0 > R13: ffff88801d8cbe88 R14: ffff88802ce66aa8 R15: 1ffff11003b197d1 > FS: 0000000000000000(0000) GS:ffff888063a00000(0000) knlGS:0000000000000000 > CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > CR2: 00007ff0448ce6b0 CR3: 00000000244bc000 CR4: 0000000000350ef0 > DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 > DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 > Call Trace: > <TASK> > exit_mmap+0x435/0xa20 mm/mmap.c:3352 This is free_pgtables(&tlb, &vmi.mas, vma, FIRST_USER_ADDRESS, USER_PGTABLES_CEILING, true); But on line 3349 we have: mmap_write_lock(mm); None of the calls before free_pgtables() unlock this lock so that's super weird. I'm not sure how this could possibly happen? > __mmput+0x114/0x3b0 kernel/fork.c:1346 > exit_mm+0x207/0x2e0 kernel/exit.c:567 > do_exit+0x996/0x2560 kernel/exit.c:863 > do_group_exit+0x1fd/0x2b0 kernel/exit.c:1025 > get_signal+0x1697/0x1730 kernel/signal.c:2909 > arch_do_signal_or_restart+0x92/0x7f0 arch/x86/kernel/signal.c:310 OK so this is exit on a signal... so not the repro? Or when the repro was killed? > exit_to_user_mode_loop kernel/entry/common.c:111 [inline] > exit_to_user_mode_prepare include/linux/entry-common.h:328 [inline] > __syscall_exit_to_user_mode_work kernel/entry/common.c:207 [inline] > syscall_exit_to_user_mode+0x95/0x280 kernel/entry/common.c:218 > do_syscall_64+0x8a/0x150 arch/x86/entry/common.c:89 > entry_SYSCALL_64_after_hwframe+0x67/0x6f > RIP: 0033:0x7fb06353406d > Code: Unable to access opcode bytes at 0x7fb063534043. > RSP: 002b:00007fb0634d10c8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 > RAX: 0000000000000002 RBX: 00007fb0635c92e8 RCX: 00007fb06353406d > RDX: 0000000020000080 RSI: 0000000000000001 RDI: 0000000000000004 > RBP: 00007fb0635c92e0 R08: 00007fb0634d1640 R09: 0000000000000000 > R10: 00007fb0634d1640 R11: 0000000000000246 R12: 00007fb0635c92ec > R13: 0000000000000000 R14: 00007fb0634f67c0 R15: 00007fb0634b1000 > </TASK> > > > -- > Yours sincerely, > Xingyu
