add fuzzer target

[rbran]

This is the target that I used to find #359 and #363.

Maybe there is something wrong with my setup, but the fuzzer is only able to get a few hundred executions per second.

This implementation is also limited by the fact that some Paths that are bigger then 255 bytes result in panic and not error. So we are limited to fuzzing paths that are 255 bytes or shorter.

I suppose having the Deku assertions being transformed from panics into errors could improve fuzzing in the future, let me know what you think.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Comparison is base (d8cc6f1) 73.19% compared to head (1a3eee3) 73.07%.
Report is 6 commits behind head on master.

Additional details and impacted files

@@            Coverage Diff             @@
##           master     #366      +/-   ##
==========================================
- Coverage   73.19%   73.07%   -0.12%     
==========================================
  Files          21       21              
  Lines        2917     2908       -9     
  Branches     2917     2908       -9     
==========================================
- Hits         2135     2125      -10     
  Misses        515      515              
- Partials      267      268       +1     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[wcampbell0x2a]

Maybe there is something wrong with my setup, but the fuzzer is only able to get a few hundred executions per second.

Even on my somewhat modern computer I get only 630 exec/s.

[wcampbell0x2a]

I suppose having the Deku assertions being transformed from panics into errors could improve fuzzing in the future, let me know what you think.

What do you mean by this? Do these exist in backhand, or deku ?

[rbran]

Even on my somewhat modern computer I get only 630 exec/s

I tried to find the time sink in the execution with flamegraph, but most of the time it was spent executing "unknowns". Once I have more time available, I'll investigate where is the slow code

What do you mean by this? Do these exist in backhand, or deku ?

Sorry, I meant the deku assertions, like in https://github.com/wcampbell0x2a/backhand/blob/master/backhand/src/dir.rs#L22

They usually result in panic, and not Result::Error, which limits the fuzzer capability to differentiate invalid input and errors on the lib.

I assume this project wants to convert those panics into errors, because the user of the lib may want to continue the execution of the program if he finds a corrupted/invalid file.

[wcampbell0x2a]

Sorry, I meant the deku assertions, like in https://github.com/wcampbell0x2a/backhand/blob/master/backhand/src/dir.rs#L22

They usually result in panic, and not Result::Error, which limits the fuzzer capability to differentiate invalid input and errors on the lib.

I assume this project wants to convert those panics into errors, because the user of the lib may want to continue the execution of the program if he finds a corrupted/invalid file.

They shouldn't result in a panic: https://github.com/sharksforarms/deku/blob/d1827d1b4ddf34def616263f0a642de9a58b1653/deku-derive/src/macros/deku_read.rs#L550C11-L550C11

[rbran]

They shouldn't result in a panic: https://github.com/sharksforarms/deku/blob/d1827d1b4ddf34def616263f0a642de9a58b1653/deku-derive/src/macros/deku_read.rs#L550C11-L550C11

If you remove the 255 limit from the fuzzer, you get this panic:

thread '<unnamed>' panicked at /home/rbran/src/backhand/backhand/src/inode.rs:49:10:
called `Result::unwrap()` on an `Err` value: Assertion("BasicSymlink.target_size field failed assertion: * target_size < 256")

This is caused by this unwrap resulted from the DekuWrite

[wcampbell0x2a]

They shouldn't result in a panic: https://github.com/sharksforarms/deku/blob/d1827d1b4ddf34def616263f0a642de9a58b1653/deku-derive/src/macros/deku_read.rs#L550C11-L550C11

If you remove the 255 limit from the fuzzer, you get this panic:

thread '<unnamed>' panicked at /home/rbran/src/backhand/backhand/src/inode.rs:49:10:
called `Result::unwrap()` on an `Err` value: Assertion("BasicSymlink.target_size field failed assertion: * target_size < 256")

This is caused by this unwrap resulted from the DekuWrite

Oh! Yes that sneaky unwrap shouldn't exist.

[rbran]

Yes that sneaky unwrap shouldn't exist

I thought about that, actually this unwrap should exist.

An error should be returned when trying to add a file with path > 255, not when trying to write a valid struct.

This unwrap is an "assert" and should only be reachable if a mistake was made in a previous part of the execution.

[wcampbell0x2a]

Yes that sneaky unwrap shouldn't exist

I thought about that, actually this unwrap should exist.

An error should be returned when trying to add a file with path > 255, not when trying to write a valid struct.

This unwrap is an "assert" and should only be reachable if a mistake was made in a previous part of the execution.

I would be of the opinion that is changed to return an Err, as it's library code I would rather return an error than unwrap/panic that users entire program.

[rbran]

I would be of the opinion that is changed to return an Err, as it's library code I would rather return an error than unwrap/panic that users entire program.

My point is that only unreachable (or equivalent) panics are allowed. In this case, the filename with more than 255 bytes should not be allowed to be added to the struct in the first place, so the unwrap can never be reached.