On Tue, Sep 13, 2022 at 12:51:42PM -0700, syzbot wrote: > Hello, > > syzbot found the following issue on: > > HEAD commit: a6b443748715 Merge branch 'for-next/core', remote-tracking.. > git tree: git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git for-kernelci > console output: https://syzkaller.appspot.com/x/log.txt?x=16271d4f080000 > kernel config: https://syzkaller.appspot.com/x/.config?x=e79d82586727c5df > dashboard link: https://syzkaller.appspot.com/bug?extid=29dc75ed37be943c610e > compiler: Debian clang version 13.0.1-++20220126092033+75e33f71c2da-1~exp1~20220126212112.63, GNU ld (GNU Binutils for Debian) 2.35.2 > userspace arch: arm64 > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=162474a7080000 > C reproducer: https://syzkaller.appspot.com/x/repro.c?x=119b6b78880000 > > Downloadable assets: > disk image: https://storage.googleapis.com/1436897f0dc0/disk-a6b44374.raw.xz > vmlinux: https://storage.googleapis.com/68c4de151fbb/vmlinux-a6b44374.xz > > IMPORTANT: if you fix the issue, please add the following tag to the commit: > Reported-by: syzbot+29dc75ed37be943c610e@xxxxxxxxxxxxxxxxxxxxxxxxx > > ntfs3: loop0: Different NTFS' sector size (1024) and media sector size (512) > ntfs3: loop0: RAW NTFS volume: Filesystem size 0.00 Gb > volume size 0.00 Gb. Mount in read-only > ntfs3: loop0: Failed to load $Extend. > Unable to handle kernel NULL pointer dereference at virtual address 0000000000000008 > Call trace: > d_flags_for_inode fs/dcache.c:1980 [inline] > __d_instantiate+0x2a0/0x2e4 fs/dcache.c:1998 > d_instantiate fs/dcache.c:2036 [inline] > d_make_root+0x64/0xa8 fs/dcache.c:2071 > ntfs_fill_super+0x1420/0x14a4 fs/ntfs/super.c:180 > get_tree_bdev+0x1e8/0x2a0 fs/super.c:1323 > ntfs_fs_get_tree+0x28/0x38 fs/ntfs3/super.c:1358 > vfs_get_tree+0x40/0x140 fs/super.c:1530 > do_new_mount+0x1dc/0x4e4 fs/namespace.c:3040 > path_mount+0x358/0x914 fs/namespace.c:3370 > do_mount fs/namespace.c:3383 [inline] > __do_sys_mount fs/namespace.c:3591 [inline] > __se_sys_mount fs/namespace.c:3568 [inline] > __arm64_sys_mount+0x2f8/0x408 fs/namespace.c:3568 > __invoke_syscall arch/arm64/kernel/syscall.c:38 [inline] > invoke_syscall arch/arm64/kernel/syscall.c:52 [inline] > el0_svc_common+0x138/0x220 arch/arm64/kernel/syscall.c:142 > do_el0_svc+0x48/0x164 arch/arm64/kernel/syscall.c:206 > el0_svc+0x58/0x150 arch/arm64/kernel/entry-common.c:624 > el0t_64_sync_handler+0x84/0xf0 arch/arm64/kernel/entry-common.c:642 > el0t_64_sync+0x18c/0x190 > Code: 79000688 52a00417 17ffff83 f9401288 (f9400508) > ---[ end trace 0000000000000000 ]--- > ---------------- > Code disassembly (best guess): > 0: 79000688 strh w8, [x20, #2] > 4: 52a00417 mov w23, #0x200000 // #2097152 > 8: 17ffff83 b 0xfffffffffffffe14 > c: f9401288 ldr x8, [x20, #32] > * 10: f9400508 ldr x8, [x8, #8] <-- trapping instruction at a guess - bollocksed inode; NULL ->i_op (should never happen; it takes actively assigning NULL to it, but apparently ntfs_read_mft() is that dumb), combined with candidate root inode somehow having S_IFLNK in ->i_mode. At the very least, inode->i_op = NULL; should *NEVER* be done; there is no legitimate reason to do that, no matter what. ->i_op initially points to empty method table; it should never point to anything that is not an object of type struct inode_operations. In particular, it should never become NULL.
