It is hard to accurately identify the impact of fuzzing on the security of free software projects. That being said, most will agree that a large part of the current CVE flow is the result of fuzz testing.

Unfortunately free software projects don't always fully profit from this fuzzing work, mostly due to mistakes being done while reporting fuzzing results: among others malformed bug reports, missing information and uncontactable reporters. These issues tend to create a counter-productive overhead to security teams and upstream developers.

This blog post is an attempt to point at the potential pitfalls when submitting fuzzing results and how to counter them by observing simple rules.

Guidelines for hassle free fuzzing

1. if you are fuzzing stable releases, always reproduce on the master branch

   This will help to catch duplicates already fixed since the last stable release.

   If the issue is not reproducible anymore, search for a duplicate in the closed bug reports. Can't find? Try to determine the commit which made the issue unreproducible, submit a new bug report and indicate this information.

2. check for open duplicates

   Found an open bug report with identical crash path? Do not open a new one and use it.

   In doubt? Open a new bug report and indicate the references of the potential duplicate.

3. submit a bug report on the project's bug tracker

   The worst thing you could possibly do would be to ask for CVE numbers without opening a bug report.

   The issue should be opened on the project's bug tracker. You can open a bug report on your distro's bug tracker but make sure the issue is also being tracked on upstream's side.

   Also, one issue per bug report! Ideally, one cve number would be assigned per bug report.

4. explain how to reproduce

   Always publish the POC. Make sure it will stay online as long as possible: do not upload it on Google Drive, DropBox, etc.

   What command triggered the crash?

   If this required a long processing time, indicate it in your bug report.

5. give information about your fuzz environment

   Indicate which versions of related libraries you are using.

   Depending on the context you might also want to indicate the affected architecture, ulimit...

6. wait for approval before asking for a CVE number

   Wait for upstream developers' approval before asking for a CVE number. Upstream may disagree that the issue is security-relevant, or may point to a non-obvious duplicate that you overlooked.

   Requesting for CVE updates takes time to projects developers, security teams members and MITRE people. Remember, each CVE assigned has a triage overhead. Spurious CVE submissions are a real issue for the entire free software community.

   In certain cases, the target project may not be very active anymore. In this case, make sure that you contacted the relevant maintainer on all appropriate channels. Without answer from them after a week, you may go ahead and ask for a CVE number.

7. don't disappear

   Developers might not be able to reproduce the issue. In this case there's nothing worse than disappearing as this forces projects developers and security teams members to spend a great deal of time just to assess reproducibility which could be done much faster with your help.