[Bug 216283] FUZZ: BUG() triggered in fs/ext4/extent.c:ext4_ext_insert_extent() when mount and operate on crafted image

[bugzilla-daemon@kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=216283

--- Comment #6 from Dave Chinner (david@fromorbit.com) ---
On Thu, Jul 28, 2022 at 09:25:10AM +0200, Lukas Czerner wrote:
> On Thu, Jul 28, 2022 at 09:22:24AM +1000, Dave Chinner wrote:
> > On Wed, Jul 27, 2022 at 01:53:07PM +0200, Lukas Czerner wrote:
> > > On Tue, Jul 26, 2022 at 01:10:24PM -0700, Darrick J. Wong wrote:
> > > > If you are going to run some scripted tool to randomly
> > > > corrupt the filesystem to find failures, then you have an
> > > > ethical and moral responsibility to do some of the work to
> > > > narrow down and identify the cause of the failure, not just
> > > > throw them at someone to do all the work.
> > > > 
> > > > --D
> > > 
> > > While I understand the frustration with the fuzzer bug reports like this
> > > I very much disagree with your statement about ethical and moral
> > > responsibility.
> > > 
> > > The bug is in the code, it would have been there even if Wenqing Liu
> > > didn't run the tool.
> > 
> > Yes, but it's not just a bug. It's a format parser exploit.
> 
> And what do you think this is exploiting? A bug in a "format parser"
> perhaps?
> 
> Are you trying both downplay it to not-a-bug and elevate it to 'security
> vulnerability' at the same time ? ;)

How did you come to that conclusion?

"not just a bug" != "not a bug".

i.e. I said the complete opposite of what your comment implies I
said...

> > > We know there are bugs in the code we just don't
> > > know where all of them are. Now, thanks to this report, we know a little
> > > bit more about at least one of them. That's at least a little useful.
> > > But you seem to argue that the reporter should put more work in, or not
> > > bother at all.
> > > 
> > > That's wrong. Really, Wenqing Liu has no more ethical and moral
> > > responsibility than you finding and fixing the problem regardless of the
> > > bug report.
> > 
> > By this reasoning, the researchers that discovered RetBleed
> > should have just published their findings without notify any of the
> > affected parties.
> > 
> > i.e. your argument implies they have no responsibility and hence are
> > entitled to say "We aren't responsible for helping anyone understand
> > the problem or mitigating the impact of the flaw - we've got our
> > publicity and secured tenure with discovery and publication!"
> > 
> > That's not _responsible disclosure_.
> 
> Look, your entire argument hinges on the assumption that this is a
> security vulnerability that could be exploited and the report makes the
> situation worse. And that's very much debatable. I don't think it is and
> Ted described it very well in his comment.

On systems that automount filesytsems when you plug in a USB drive
(which most distros do out of the box) then a crash bug during mount
is, at minimum, an annoying DOS vector. And if it can result in a
buffer overflow, then....

> Asking for more information, or even asking reported to try to narrow
> down the problem is of course fine.

Sure, nobody is questioning how we triage these issues - the
question is over how they are reported and the forum under which the
initial triage takes place

> But making sweeping claims about
> moral and ethical responsibilities is always a little suspicious and
> completely bogus in this case IMO.

Hand waving away the fact that fuzzer crash bugs won't be a security
issue without having done any investigation is pretty much the whole
problem here. This is not responsible behaviour.

Cheers,

Dave.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.