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

Reply via email to