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@xxxxxxxxxxxxx
