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

[Al Viro <viro@zeniv.linux.org.uk>]

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+4353c86db4e58720cd11@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.