Conversation
| if file.write_all(content).is_err() { | ||
| return None; | ||
| } | ||
|
|
||
| std::mem::forget(file); |
There was a problem hiding this comment.
Maybe instead of wrapping, calling write_all and forget we can just do libc::write instead?
There was a problem hiding this comment.
This way the cleanup on error or partial write is handled, with libc::write the return code would have to be checked and handled.
There was a problem hiding this comment.
Hmm, I'm not sure how this file is used here. CTRL + F for disk_images_corpus yields no results.
There was a problem hiding this comment.
The zip file is the seed corpus for the fuzzers which work with disk images, otherwise they waste a lot of time trying to guess magic numbers. I added a FUZZING.md which explains how it was created and how to use it.
There was a problem hiding this comment.
Hmm, I think I am still puzzled about this. So before running fuzzing we need to unpack these, got it but then I don't see anything in individual fuzz_targets/*.rs files that would make use of these images (e.g. I don't see any reference to small_fat32.img or small_ext4.img). I presume there is something that picks things up from fuzz/corpus folder but is there some documentation I can read about this?
There was a problem hiding this comment.
Correct the fuzzing, corpus handling, input mutation and coverage tracking is handled by libfuzzer. The Rust files in fuzz_target directory only define the target specific code, the boilerplate is handled by the fuzz_target libfuzzer macro (https://github.com/rust-fuzz/libfuzzer/blob/main/src/lib.rs#L226).
The fuzzer can start with an empty corpus directory or with some "interesting" input pre-seeding to get the fuzzer faster to the interesting part of the code instead of waiting to guess the well known file headers from scratch (https://llvm.org/docs/LibFuzzer.html#corpus). Essentially libfuzzer treats the corpus files as raw byte input, which happens to be disk images for GRR disk timeline fuzzing, but they can be PNG/JPEG files for image parsing libraries.
2 participants
No description provided.