[syzbot] kernel panic: stack is corrupted in lock_release (3)

[syzbot]

Hello,

syzbot found the following issue on:

HEAD commit: 3db61221f4e8 Merge tag 'io_uring-6.0-2022-09-23' of git://..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=10135a88880000
kernel config: https://syzkaller.appspot.com/x/.config?x=c221af36f6d1d811
dashboard link: https://syzkaller.appspot.com/bug?extid=4353c86db4e58720cd11
compiler: Debian clang version 13.0.1-++20220126092033+75e33f71c2da-1~exp1~20220126212112.63, GNU ld (GNU Binutils for Debian) 2.35.2
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1792e6e4880000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1059fcdf080000

IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+4353c8...@syzkaller.appspotmail.com

loop0: detected capacity change from 0 to 264192
Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in: lock_release+0x7f4/0x820
CPU: 0 PID: 9489 Comm: syz-executor322 Not tainted 6.0.0-rc6-syzkaller-00291-g3db61221f4e8 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/26/2022
Call Trace:
<TASK>
__dump_stack lib/dump_stack.c:88 [inline]
dump_stack_lvl+0x1b1/0x28e lib/dump_stack.c:106
panic+0x2d6/0x715 kernel/panic.c:274
__stack_chk_fail+0x12/0x20 kernel/panic.c:706
lock_release+0x7f4/0x820
__raw_spin_unlock include/linux/spinlock_api_smp.h:141 [inline]
_raw_spin_unlock+0x12/0x40 kernel/locking/spinlock.c:186
spin_unlock include/linux/spinlock.h:389 [inline]
inode_wait_for_writeback+0x242/0x2c0 fs/fs-writeback.c:1474
evict+0x277/0x620 fs/inode.c:662
ntfs_fill_super+0x3af3/0x42a0 fs/ntfs3/super.c:1190
get_tree_bdev+0x400/0x620 fs/super.c:1323
vfs_get_tree+0x88/0x270 fs/super.c:1530
do_new_mount+0x289/0xad0 fs/namespace.c:3040
do_mount fs/namespace.c:3383 [inline]
__do_sys_mount fs/namespace.c:3591 [inline]
__se_sys_mount+0x2d3/0x3c0 fs/namespace.c:3568
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x63/0xcd
RIP: 0033:0x7fe603d0835a
Code: 48 c7 c2 c0 ff ff ff f7 d8 64 89 02 b8 ff ff ff ff eb d2 e8 08 01 00 00 0f 1f 84 00 00 00 00 00 49 89 ca b8 a5 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 c0 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007ffd6ef632a8 EFLAGS: 00000286 ORIG_RAX: 00000000000000a5
RAX: ffffffffffffffda RBX: 00007ffd6ef63300 RCX: 00007fe603d0835a
RDX: 0000000020000000 RSI: 0000000020000100 RDI: 00007ffd6ef632c0
RBP: 00007ffd6ef632c0 R08: 00007ffd6ef63300 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000286 R12: 0000000020000bc0
R13: 0000000000000003 R14: 0000000000000004 R15: 0000000000000068
</TASK>
Kernel Offset: disabled
Rebooting in 86400 seconds..


---
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 syzk...@googlegroups.com.

syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
syzbot can test patches for this issue, for details see:
https://goo.gl/tpsmEJ#testing-patches

[Al Viro]

On Sun, Sep 25, 2022 at 03:47:38AM -0700, syzbot wrote:
> Hello,
>
> syzbot found the following issue on:
>
> HEAD commit: 3db61221f4e8 Merge tag 'io_uring-6.0-2022-09-23' of git://..
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=10135a88880000
> kernel config: https://syzkaller.appspot.com/x/.config?x=c221af36f6d1d811
> dashboard link: https://syzkaller.appspot.com/bug?extid=4353c86db4e58720cd11
> compiler: Debian clang version 13.0.1-++20220126092033+75e33f71c2da-1~exp1~20220126212112.63, GNU ld (GNU Binutils for Debian) 2.35.2
> syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1792e6e4880000
> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1059fcdf080000
>
> IMPORTANT: if you fix the issue, please add the following tag to the commit:
> Reported-by: syzbot+4353c8...@syzkaller.appspotmail.com

[ntfs_fill_super() failure exits are still buggered]

Folks, could syzbot be taught that ntfs involved in testing means that
ntfs maintainers need to be on Cc?

FWIW,

1) failing d_make_root() does *NOT* need the caller to drop inode; it consumes
inode reference itself, precisely to make that failure exits easier.

2) you never set ->i_op to NULL. Initial value is to an empty method table;
nothing out of alloc_inode(), let alone iget5_locked() should ever see
NULL ->i_op there.

3) the same goes for ->i_fop; it should never be NULL. Initial value points
to an empty method table; if you don't want any methods, leave it as-is.
Yes, even for symlinks.

That - from quick eyeballing the code in question. There might be more (and
almost certainly is). The thing is, ntfs3 clearly corrupts memory of failure
exits in mount, and syzbot reports in that direction really ought to go to ntfs
folks; Cc to fsdevel is OK, but at least mark those as likely to be ntfs-related.

[syzbot]

Auto-closing this bug as obsolete.
No recent activity, existing reproducers are no longer triggering the issue.