Re: Multiple bugs found by fuzzing BTRFS

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 [off-list ref]:

Hi,

thanks for the testing and reports.

On Mon, Aug 29, 2016 at 08:06:24AM +0200, Lukas Lueg wrote:

quoted

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.