Re: Null-Pointer Deference in hfs.ko (Linux 4.15.0-15.16 Ubuntu)

["Darrick J. Wong" <darrick.wong@oracle.com>]

On Thu, Apr 19, 2018 at 11:44:02AM +1000, Dave Chinner wrote:
> On Wed, Apr 18, 2018 at 10:59:06AM -0700, Darrick J. Wong wrote:
> > On Wed, Apr 18, 2018 at 10:30:28AM -0700, Matthew Wilcox wrote:
> > > On Wed, Apr 18, 2018 at 06:26:41PM +0200, Sergej Schumilo wrote:
> > > > Dear all,
> > > > The following null pointer dereference bug was found by a
> > > > modified version of the kAFL fuzzer
> > > > (https://github.com/RUB-SysSec/kAFL). I have attached the
> > > > causing hfs filesystem image, the dmesg report and the source
> > > > code of a simple mounting tool to reproduce this issue.
> > > > 
> > > > A local users who have been granted the privileges necessary to
> > > > mount filesystems (or a system components which auto mounts
> > > > filesystems) could trigger a null pointer dereference or a
> > > > kernel panic (depending on panic_on_oops).
> > > 
> > > I have to say this isn't going to rank very highly in terms of bugs we're
> > > likely to spend a lot of time on.  Almost nobody uses HFS on Linux,
> > > and it has no maintainer.  I'd suggest that Ubuntu disables it from
> > > their configuration, or if it's important to them, that they contribute
> > > somebody's time to working on it.
> > > 
> > > You'd probably get a more interesting response if you fuzzed ext4, btrfs
> > > or XFS.  Or FAT or iso9660; things people are likely to have an USB keys.
> > > There may be a tooling problem here where some filesystems should be
> > > whitelisted for automounting.  I just don't think you're going to find
> > > anyone interested in fixing this.
> > 
> > They already are fuzzing ext4 and xfs and generating a fair amount of
> > list / bugzilla traffic.  Regrettable that almost nobody sends us
> > patches to fix the things they find, which at some point is just going
> > to make the review backlog problems worse as peoples' attention get
> > diverted to triaging the flood of reports.
> 
> I think that the other thing to note here is that the fuzzing being
> done is so far from the state of the art that it's probably harmful
> to ongoing development rather than improving anything.
> 
> i.e. Fuzzing legacy filesystem formats that don't have CRC
> protection for the metadata and/or redundant information to reliably
> detect corruption doesn't help us improve the resilience of modern
> filesystems.  We know we cannot detect random bit corruptions in
> these legacy filesystem formats and we've known this for a long
> time. In the case of XFS, we fixed this vulnerability to random bit
> corruptions years ago and we have defaulted to creating CRC enabled
> filesystems for the past few years. Hence there's a large (and ever
> growing!) pool of users whose filesystems will detect random bit
> corruptions in metadata and just do the right thing.
> 
> i.e. random bit fuzzing of the legacy format doesn't help us find
> problems that we'll come across in the future, because we know we
> our filesystems already reject >99.999% of random structure
> corruptions that random bit fuzzers introduce via the CRC checking
> mechanisms. Spending time chasing stuff like this down takes away
> from doing things like making filesystem be able to do instantenous
> online repair of detected corruptions.

Or at least write new CRCs in anger like I do. >:O

> So what we really need to know about is the corruption problems that
> get through the CRC checking and the more robust verification that
> the current on-disk formats fail to catch.  We've already got
> CRC-defeating, structure aware fuzzing in fstests for v5 filesystems
> [see common/fuzzy and the 75+ tests that make use of that
> infrastructure for fuzzing XFS filesystems].

Seriously.

$ grep fuzzer ./xfstests/tests/xfs/group  | wc -l
112

Granted, the online fsck fuzzers (350-430) spray false positives
everywhere so you'll want to figure out a baseline of what's broken (ok
ok I have one djwong/xfstests.git on kernel.org) and figure out which
ones look interesting.

> Anyone wanting to fuzz XFS filesystems needs to look as this stuff
> and then either build on top of it or make a better tool we can use
> for doing this sort of testing inside fstests. i.e. adding more
> tests to fstests that improve fuzzing coverage of v5 filesystems is
> far more useful to us than throwing broken v4 filesystem images over
> the wall at us.

Or just improving the ones we have already.  That giant patchbomb I sent
to the xfs list yesterday?  That has a /lot/ of patches to fix problems
that the fuzzers have been smashing into on a regular basis, and that's
not including the online fsck code.  That's what I meant when I say that
my employers care enough to let me fuzz, triage, and fix, not just dump
reports on the mailing list.

--D

> 
> > Sorry just being a grumpy maintainer.
> 
> Sorry, just being a grumpy engineer.
> 
> Cheers,
> 
> Dave.
> -- 
> Dave Chinner
> david@fromorbit.com