Why dry run crashes are regarded as a normal queue corpus? #1810
Replies: 3 comments 2 replies
-
the reasoning behind is that what is in a corpus is considered a known crash and the goal of fuzzing is to find new/unknown crashes what use would there be to have a crash in the starting seeds? |
Beta Was this translation helpful? Give feedback.
-
afaik oss-fuzz tests the corpus directory for the crashes so also the queue directory, and the crash will be part of the queue (just not being picked for fuzzing). or does oss-fuzz do that differently? |
Beta Was this translation helpful? Give feedback.
-
Thank you for the information. https://github.com/google/clusterfuzz/blob/eddca92265eb201bc3fb70062e9310960113c714/src/clusterfuzz/_internal/bot/fuzzers/afl/launcher.py#L911C24-L911C43 But still, I think it will be good to provide the mode which can categorize the crashes among the input(seeds) as new crash. (e.g. AFL_CRASH_ON_SEED_AS_KNOWN_CRASH=0) How do you think about this feature? if you think it's not bad, I'd like to work on this one. |
Beta Was this translation helpful? Give feedback.
-
Hi all,
I'm experimenting one of the oss-fuzz application on my local machine,
and observed that AFLplusplus doesn't categorize the crashes from dry run as a crash.
and it is just regarded as one of queue corpus.
I think this is problematic for automatic cluster fuzzing platforms(e.g. oss-fuzz, clusterfuzz).
After the deployment of each application, oss-fuzz will re-run this application with the same input corpora, but with the different code. and some of this input can be result in crash.
however, with current strategy of
perform_dry_run
, AFL++ can not report this new bug from dry run to ossfuzz.Is there any features that are already implemented for this issue or something I missed?
Thank you.
Beta Was this translation helpful? Give feedback.
All reactions