Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Thu, 29 Sep 2022 21:50:40 +0100
From:   Al Viro <viro@zeniv.linux.org.uk>
To:     syzbot <syzbot+84b7b87a6430a152c1f4@syzkaller.appspotmail.com>
Cc:     linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
        syzkaller-bugs@googlegroups.com
Subject: Re: [syzbot] kernel panic: stack is corrupted in
 writeback_single_inode
Message-ID: <YzYFIK/jFiN6WEzT@ZenIV>
References: <0000000000008ea2da05e979435f@google.com>
 <0000000000000f962805e9d6ae62@google.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <0000000000000f962805e9d6ae62@google.com>
Sender: Al Viro <viro@ftp.linux.org.uk>
Precedence: bulk

On Thu, Sep 29, 2022 at 01:25:36PM -0700, syzbot wrote:
> syzbot has found a reproducer for the following issue on:
> 
> HEAD commit:    c3e0e1e23c70 Merge tag 'irq_urgent_for_v6.0' of git://git...
> git tree:       upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=17ab519c880000
> kernel config:  https://syzkaller.appspot.com/x/.config?x=ba0d23aa7e1ffaf5
> dashboard link: https://syzkaller.appspot.com/bug?extid=84b7b87a6430a152c1f4
> 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=157c2000880000
> C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=105224b8880000
> 
> Downloadable assets:
> disk image: https://storage.googleapis.com/syzbot-assets/e7f1f925f94e/disk-c3e0e1e2.raw.xz
> vmlinux: https://storage.googleapis.com/syzbot-assets/830dabeedf0d/vmlinux-c3e0e1e2.xz
> 
> IMPORTANT: if you fix the issue, please add the following tag to the commit:
> Reported-by: syzbot+84b7b87a6430a152c1f4@syzkaller.appspotmail.com

... and you _still_ have not bothered to Cc ntfs maintainers.
Once more, with feeling:
	If you are fuzzing something (ntfs, in this case), the people most
interested in your report are the maintainers of the code in question.
You know that from the moment you put the test together.  No matter where
exactly the oops gets triggered, what it looks like, etc.