Re: [syzbot] BUG: unable to handle kernel NULL pointer dereference in __d_instantiate

[Al Viro]

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.