linux-kernel - Re: [syzbot] [jfs?] INFO: task hung in path

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20240125-addition-audienz-c955ab3c8435@brauner>
Date: Thu, 25 Jan 2024 17:47:19 +0100
From: Christian Brauner <brauner@...nel.org>
To: Jens Axboe <axboe@...nel.dk>
Cc: syzbot <syzbot+fb337a5ea8454f5f1e3f@...kaller.appspotmail.com>, 
	hdanton@...a.com, jack@...e.cz, jfs-discussion@...ts.sourceforge.net, 
	linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org, shaggy@...nel.org, 
	syzkaller-bugs@...glegroups.com
Subject: Re: [syzbot] [jfs?] INFO: task hung in path_mount (2)

On Thu, Jan 25, 2024 at 09:11:34AM -0700, Jens Axboe wrote:
> On Thu, Jan 25, 2024 at 9:08?AM Christian Brauner <brauner@...nel.org> wrote:
> >
> > On Thu, Jan 25, 2024 at 03:59:03AM -0800, syzbot wrote:
> > > syzbot suspects this issue was fixed by commit:
> > >
> > > commit 6f861765464f43a71462d52026fbddfc858239a5
> > > Author: Jan Kara <jack@...e.cz>
> > > Date:   Wed Nov 1 17:43:10 2023 +0000
> > >
> > >     fs: Block writes to mounted block devices
> > >
> > > bisection log:  https://syzkaller.appspot.com/x/bisect.txt?x=13175a53e80000
> > > start commit:   2ccdd1b13c59 Linux 6.5-rc6
> > > git tree:       upstream
> > > kernel config:  https://syzkaller.appspot.com/x/.config?x=9c37cc0e4fcc5f8d
> > > dashboard link: https://syzkaller.appspot.com/bug?extid=fb337a5ea8454f5f1e3f
> > > syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=17ba5d53a80000
> > > C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=14265373a80000
> > >
> > > If the result looks correct, please mark the issue as fixed by replying with:
> >
> > #syz fix: fs: Block writes to mounted block devices
> 
> Like Dave replied a few days ago, I'm kind of skeptical on all of these
> bugs being closed by this change. I'm guessing that they are all
> resolved now because a) the block writes while mounted option was set to
> Y, and b) the actual bug is just masked by that.
> 
> Maybe this is fine, but it does seem a bit... sketchy? The bugs aren't
> really fixed, and what happens if someone doesn't turn on that option?
> If it's required, perhaps it should not be an option at all? Though
> that'd seem to be likely to break some funky use cases, whether they are
> valid or not.

We have no way of actually testing or verifying this stuff and a lot of
these have been around for a long time. For example, this report here
has a C reproducer but following the actual dashboard link that
reproducer is striked-through which supposedly means that it isn't valid
or reliable. And no other reproducer ever showed up.

As far as I can see we should just close reports such as. If this is a
real bug that is separate from the ability to mount to writed block
devices then one should hope that syzbot finds another reproducer that
let's us really analyze the bug?

A separate issue is that syzbot keeps suggesting as all of these being
closable because of this. So how serious can we take this and how much
time can/should we spend given that we got ~20 or more of these mails in
the last two weeks or so.

I have no better answers than this tbh. And fwiw, apart from this one I
haven't closed a single bug based on this.

And yes, ideally the ability to write to mounted block devices should be
turned off. But we'll have to let it trickle into the individual
distributions first and make remaining userspace tools that rely on this
move to alternate apis before we can make any serious effort.