On Tue, Oct 31, 2023 at 7:39 PM Rik van Riel <riel@xxxxxxxxxxx> wrote: > > On Sun, 2023-10-29 at 02:27 -0700, syzbot wrote: > > > > commit bf4916922c60f43efaa329744b3eef539aa6a2b2 > > Author: Rik van Riel <riel@xxxxxxxxxxx> > > Date: Fri Oct 6 03:59:07 2023 +0000 > > > > hugetlbfs: extend hugetlb_vma_lock to private VMAs > > > > I've been trying to reproduce the issue here, but the test > case has been running for 4+ hours now on a KVM guest, with > KASAN and CONFIG_PROVE_LOCKING enabled. No crashes yet. FWIW you may also try to use the syzbot-built kernel shared via the "Downloadable assets" section[1]. I've just run the C repro against it and it crashed immediately. [ 66.222816][ T5095] general protection fault, probably for non-canonical address 0xdffffc000000001d: 0000 [#1] PREEMPT SMP KASAN [ 66.227224][ T5095] KASAN: null-ptr-deref in range [0x00000000000000e8-0x00000000000000ef] [ 66.230109][ T5095] CPU: 0 PID: 5095 Comm: repro Not tainted 6.6.0-rc7-syzkaller-00142-g888cf78c29e2 #0 [1] Here are the instructions with commands to copy-paste: https://github.com/google/syzkaller/blob/master/docs/syzbot_assets.md -- Aleksandr > > I'll try adapting the config file from syzkaller so the > resulting kernel boots here, but this is not looking like > an easy reproducer so far... > > The crash is also confusing me somewhat, because it looks > like hugetlb_vma_lock_write() is passing a nonsense (very small > value) resv_map->rw_sema pointer down to down_write, but the > code has some protection against that: > > static inline bool __vma_private_lock(struct vm_area_struct *vma) > { > return (!(vma->vm_flags & VM_MAYSHARE)) && vma- > >vm_private_data; > } > > void hugetlb_vma_lock_write(struct vm_area_struct *vma) > { > if (__vma_shareable_lock(vma)) { > struct hugetlb_vma_lock *vma_lock = vma- > >vm_private_data; > > down_write(&vma_lock->rw_sema); > } else if (__vma_private_lock(vma)) { > struct resv_map *resv_map = vma_resv_map(vma); > > down_write(&resv_map->rw_sema); > } > } > > At fork time, vma->vm_private_data gets cleared in the child > process for MAP_PRIVATE hugetlb VMAs. > > I do not see anything that would leave behind a tiny, but > non-zero value in that pointer. > > I'll keep poking at this, but I don't know if it will > reproduce here. > > > general protection fault, probably for non-canonical address > > 0xdffffc000000001d: 0000 [#1] PREEMPT SMP KASAN > > KASAN: null-ptr-deref in range [0x00000000000000e8- > > 0x00000000000000ef] > > CPU: 0 PID: 5048 Comm: syz-executor139 Not tainted 6.6.0-rc7- > > syzkaller-00142-g888cf78c29e2 #0 > > Hardware name: Google Google Compute Engine/Google Compute Engine, > > BIOS Google 10/09/2023 > > RIP: 0010:__lock_acquire+0x109/0x5de0 kernel/locking/lockdep.c:5004 > > Code: 45 85 c9 0f 84 cc 0e 00 00 44 8b 05 c1 1e 42 0b 45 85 c0 0f 84 > > be 0d 00 00 48 ba 00 00 00 00 00 fc ff df 4c 89 d1 48 c1 e9 03 <80> > > 3c 11 00 0f 85 e8 40 00 00 49 81 3a a0 d9 5f 90 0f 84 96 0d 00 > > RSP: 0018:ffffc90003aa7798 EFLAGS: 00010016 > > > > RAX: ffff88807a0b9dc0 RBX: 1ffff92000754f23 RCX: 000000000000001d > > RDX: dffffc0000000000 RSI: 0000000000000000 RDI: 00000000000000e8 > > RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000001 > > R10: 00000000000000e8 R11: 0000000000000000 R12: 0000000000000000 > > R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 > > FS: 0000000000000000(0000) GS:ffff8880b9800000(0000) > > knlGS:0000000000000000 > > CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > > CR2: 0000000020000280 CR3: 00000000758bf000 CR4: 0000000000350ef0 > > Call Trace: > > <TASK> > > lock_acquire kernel/locking/lockdep.c:5753 [inline] > > lock_acquire+0x1ae/0x510 kernel/locking/lockdep.c:5718 > > down_write+0x93/0x200 kernel/locking/rwsem.c:1573 > > hugetlb_vma_lock_write mm/hugetlb.c:300 [inline] > > hugetlb_vma_lock_write+0xae/0x100 mm/hugetlb.c:291 > > __hugetlb_zap_begin+0x1e9/0x2b0 mm/hugetlb.c:5447 > > hugetlb_zap_begin include/linux/hugetlb.h:258 [inline] > > unmap_vmas+0x2f4/0x470 mm/memory.c:1733 > > exit_mmap+0x1ad/0xa60 mm/mmap.c:3230 > > __mmput+0x12a/0x4d0 kernel/fork.c:1349 > > mmput+0x62/0x70 kernel/fork.c:1371 > > exit_mm kernel/exit.c:567 [inline] > > do_exit+0x9ad/0x2a20 kernel/exit.c:861 > > __do_sys_exit kernel/exit.c:991 [inline] > > __se_sys_exit kernel/exit.c:989 [inline] > > __x64_sys_exit+0x42/0x50 kernel/exit.c:989 > > do_syscall_x64 arch/x86/entry/common.c:50 [inline] > > do_syscall_64+0x38/0xb0 arch/x86/entry/common.c:80 > > entry_SYSCALL_64_after_hwframe+0x63/0xcd > > RIP: 0033:0x7ff2b7a78ab9 > > Code: Unable to access opcode bytes at 0x7ff2b7a78a8f. > > RSP: 002b:00007fff926ea6b8 EFLAGS: 00000246 ORIG_RAX: > > 000000000000003c > > RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007ff2b7a78ab9 > > RDX: 00007ff2b7ab23f3 RSI: 0000000000000000 RDI: 0000000000000000 > > RBP: 000000000000cfda R08: 0000000000000000 R09: 0000000000000006 > > R10: 0000000000000000 R11: 0000000000000246 R12: 00007fff926ea6cc > > R13: 431bde82d7b634db R14: 0000000000000001 R15: 0000000000000001 > > </TASK> > > Modules linked in: > > ---[ end trace 0000000000000000 ]--- > > RIP: 0010:__lock_acquire+0x109/0x5de0 kernel/locking/lockdep.c:5004 > > Code: 45 85 c9 0f 84 cc 0e 00 00 44 8b 05 c1 1e 42 0b 45 85 c0 0f 84 > > be 0d 00 00 48 ba 00 00 00 00 00 fc ff df 4c 89 d1 48 c1 e9 03 <80> > > 3c 11 00 0f 85 e8 40 00 00 49 81 3a a0 d9 5f 90 0f 84 96 0d 00 > > RSP: 0018:ffffc90003aa7798 EFLAGS: 00010016 > > RAX: ffff88807a0b9dc0 RBX: 1ffff92000754f23 RCX: 000000000000001d > > RDX: dffffc0000000000 RSI: 0000000000000000 RDI: 00000000000000e8 > > RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000001 > > R10: 00000000000000e8 R11: 0000000000000000 R12: 0000000000000000 > > R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 > > FS: 0000000000000000(0000) GS:ffff8880b9800000(0000) > > knlGS:0000000000000000 > > CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > > CR2: 0000000020000280 CR3: 00000000758bf000 CR4: 0000000000350ef0 > > ---------------- > > Code disassembly (best guess): > > 0: 45 85 c9 test %r9d,%r9d > > 3: 0f 84 cc 0e 00 00 je 0xed5 > > 9: 44 8b 05 c1 1e 42 0b mov 0xb421ec1(%rip),%r8d # > > 0xb421ed1 > > 10: 45 85 c0 test %r8d,%r8d > > 13: 0f 84 be 0d 00 00 je 0xdd7 > > 19: 48 ba 00 00 00 00 00 movabs $0xdffffc0000000000,%rdx > > 20: fc ff df > > 23: 4c 89 d1 mov %r10,%rcx > > 26: 48 c1 e9 03 shr $0x3,%rcx > > * 2a: 80 3c 11 00 cmpb $0x0,(%rcx,%rdx,1) <-- > > trapping instruction > > 2e: 0f 85 e8 40 00 00 jne 0x411c > > 34: 49 81 3a a0 d9 5f 90 cmpq $0xffffffff905fd9a0,(%r10) > > 3b: 0f .byte 0xf > > 3c: 84 .byte 0x84 > > 3d: 96 xchg %eax,%esi > > 3e: 0d .byte 0xd > > > > > > --- > > 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. > > For information about bisection process see: > > https://goo.gl/tpsmEJ#bisection > > > > If the bug is already fixed, let syzbot know by replying with: > > #syz fix: exact-commit-title > > > > If you want syzbot to run the reproducer, reply with: > > #syz test: git://repo/address.git branch-or-commit-hash > > If you attach or paste a git patch, syzbot will apply it before > > testing. > > > > If you want to overwrite bug's subsystems, reply with: > > #syz set subsystems: new-subsystem > > (See the list of subsystem names on the web dashboard) > > > > If the bug is a duplicate of another bug, reply with: > > #syz dup: exact-subject-of-another-report > > > > If you want to undo deduplication, reply with: > > #syz undup > > > > -- > All Rights Reversed. > > -- > You received this message because you are subscribed to the Google Groups "syzkaller-bugs" group. > To unsubscribe from this group and stop receiving emails from it, send an email to syzkaller-bugs+unsubscribe@xxxxxxxxxxxxxxxx. > To view this discussion on the web visit https://groups.google.com/d/msgid/syzkaller-bugs/bce5df0508221ab30a1fb121a219034631abedf5.camel%40surriel.com.
