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