I'll report new issues to bz as they turn up from the current round only if they represent a yet unreported kind of problem (e.g. there are stack-based buffer over- and underruns lurking, I lost them due to a bug in my setup, though). The next round will be much faster as I've now vastly improved my automatic bug triage and fuzzing speed.
I lost interest once after bugs went unanswered - there are bugs still open and unanswered from 2015/04. I hope this won't be a problem this time. 2016-08-29 19:02 GMT+02:00 David Sterba <dste...@suse.cz>: > Hi, > > thanks for the testing and reports. > > On Mon, Aug 29, 2016 at 08:06:24AM +0200, Lukas Lueg wrote: >> I've now spent around 160 hours of fuzzing BTRFS, here are the crashes >> I found so far. Every type of crash is reported only once although >> there are usually multiple locations where they show up (especially >> heap-use-after-free and calls to abort()). >> >> The following bug reports have attached to them images of ą18kb which >> expand to 16mb and reproduce a crash when running btrfsck; they all >> have been revirginized so CRC- and FSID-checks pass by a vanilla >> btrfsck. >> >> >> Use-after-free, shows up all over the place: >> https://bugzilla.kernel.org/show_bug.cgi?id=153641 >> >> Segfault in memcpy, yeah: https://bugzilla.kernel.org/show_bug.cgi?id=154021 >> >> Run-off-the-mill buffer-overflow: >> https://bugzilla.kernel.org/show_bug.cgi?id=154961 >> >> Endless loop in btrfsck: https://bugzilla.kernel.org/show_bug.cgi?id=155151 >> >> Calls to abort() by lack of error paths: >> https://bugzilla.kernel.org/show_bug.cgi?id=155181 >> >> Division by zero, the old problem of computing stripe_size: >> https://bugzilla.kernel.org/show_bug.cgi?id=155201 >> >> >> There are many more crashes like the above; how do you guys want them >> to be reported? > > It's good to have them tracked in bugzilla, I'm CCed on all new > bugreports so I'll know about them and you don't need to post them to > the mailinglist. It'd be great to send a summary mail to the mailinglist > when you do the testing round. > > Please give us some time to fix the issues before the next round, to > avoid reporting potentially fixed issues. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html