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

[Dave Chinner <david@fromorbit.com>]

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.

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].

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.

> Sorry just being a grumpy maintainer.

Sorry, just being a grumpy engineer.

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com