All of lore.kernel.org
 help / color / mirror / Atom feed
* Multiple bugs found by fuzzing BTRFS
@ 2016-08-29  6:06 Lukas Lueg
  2016-08-29  6:20 ` Qu Wenruo
  2016-08-29 17:02 ` David Sterba
  0 siblings, 2 replies; 6+ messages in thread
From: Lukas Lueg @ 2016-08-29  6:06 UTC (permalink / raw)
  To: linux-btrfs

Hi,

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?


Best regards

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Multiple bugs found by fuzzing BTRFS
  2016-08-29  6:06 Multiple bugs found by fuzzing BTRFS Lukas Lueg
@ 2016-08-29  6:20 ` Qu Wenruo
  2016-08-29  6:56   ` Lukas Lueg
  2016-08-29 17:02 ` David Sterba
  1 sibling, 1 reply; 6+ messages in thread
From: Qu Wenruo @ 2016-08-29  6:20 UTC (permalink / raw)
  To: Lukas Lueg, linux-btrfs

Thanks for your fuzzing images.

Quite helpful.

At 08/29/2016 02:06 PM, Lukas Lueg wrote:
> Hi,
>
> 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

Digging, while it's a little different from the original one.

BTW, for btrfsck bugs, would you please also try the new low memory mode?
For example, the above image won't trigger bug in low memory mode.

Thanks,
Qu
>
>
> There are many more crashes like the above; how do you guys want them
> to be reported?
>
>
> Best regards
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
>



^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Multiple bugs found by fuzzing BTRFS
  2016-08-29  6:20 ` Qu Wenruo
@ 2016-08-29  6:56   ` Lukas Lueg
  0 siblings, 0 replies; 6+ messages in thread
From: Lukas Lueg @ 2016-08-29  6:56 UTC (permalink / raw)
  To: Qu Wenruo; +Cc: linux-btrfs

I will let the current setup run for another 200 hours and deal with
low memory mode then. Having had a quick glance at it, at least some
of the bugs mentioned above show up and should get fix beforehand.

2016-08-29 8:20 GMT+02:00 Qu Wenruo <quwenruo@cn.fujitsu.com>:
> Thanks for your fuzzing images.
>
> Quite helpful.
>
> At 08/29/2016 02:06 PM, Lukas Lueg wrote:
>>
>> Hi,
>>
>> 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
>
>
> Digging, while it's a little different from the original one.
>
> BTW, for btrfsck bugs, would you please also try the new low memory mode?
> For example, the above image won't trigger bug in low memory mode.
>
> Thanks,
> Qu
>>
>>
>>
>> There are many more crashes like the above; how do you guys want them
>> to be reported?
>>
>>
>> Best regards
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>
>>
>
>

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Multiple bugs found by fuzzing BTRFS
  2016-08-29  6:06 Multiple bugs found by fuzzing BTRFS Lukas Lueg
  2016-08-29  6:20 ` Qu Wenruo
@ 2016-08-29 17:02 ` David Sterba
  2016-08-29 18:47   ` Lukas Lueg
  1 sibling, 1 reply; 6+ messages in thread
From: David Sterba @ 2016-08-29 17:02 UTC (permalink / raw)
  To: Lukas Lueg; +Cc: linux-btrfs

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.

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Multiple bugs found by fuzzing BTRFS
  2016-08-29 17:02 ` David Sterba
@ 2016-08-29 18:47   ` Lukas Lueg
  2016-08-30 11:09     ` David Sterba
  0 siblings, 1 reply; 6+ messages in thread
From: Lukas Lueg @ 2016-08-29 18:47 UTC (permalink / raw)
  To: dsterba, linux-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 <dsterba@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.

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Multiple bugs found by fuzzing BTRFS
  2016-08-29 18:47   ` Lukas Lueg
@ 2016-08-30 11:09     ` David Sterba
  0 siblings, 0 replies; 6+ messages in thread
From: David Sterba @ 2016-08-30 11:09 UTC (permalink / raw)
  To: Lukas Lueg; +Cc: linux-btrfs

On Mon, Aug 29, 2016 at 08:47:10PM +0200, Lukas Lueg wrote:
> 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.

Yeah, the lack if replies is unfortunate and happens. There's a
disproportion between number of people who report bugs and who go
through them and fix.  I personally look out for the fuzzing bugs as
they usually come with an image and it's easy to create a testcase from
them, reproducible bugs also tend to get fixes faster.

I must have missed the bugs though, there are 3 fuzzed images, reported
by you in bugs 96971, 97191 and 97271. I see two more (97031 and 97021)
and will look into them.

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2016-08-30 11:11 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-08-29  6:06 Multiple bugs found by fuzzing BTRFS Lukas Lueg
2016-08-29  6:20 ` Qu Wenruo
2016-08-29  6:56   ` Lukas Lueg
2016-08-29 17:02 ` David Sterba
2016-08-29 18:47   ` Lukas Lueg
2016-08-30 11:09     ` David Sterba

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.