Add graceful handling of expected exceptions in fuzz_submodule.py by DaveLak · Pull Request #1922 · gitpython-developers/GitPython
added 5 commits
May 30, 2024 13:46Fixes: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=69350 **`IsADirectoryError`** Fuzzer provided input data can sometimes produce filenames that look like directories and raise `IsADirectoryError` exceptions which crash the fuzzer. This commit catches those cases and returns -1 to instruct libfuzzer that the inputs are not valuable to add to the corpus. **`FileExistsError`** Similar to the above, this is a possible exception case produced by the fuzzed data and not a bug so its handled the same.
Adds a utility function to limit the maximum file name legnth produced by the fuzzer to a max size dictated by the host its run on.
The fuzzer was having trouble analyzing `fuzz_submodule.py` when using the `atheris.instrument_imports()` context manager. Switching to `atheris.instrument_all()` instead slightly increases the startup time for the fuzzer, but significantly improves the fuzzing engines ability to identify new coverage. The changes here also disable warnings that are logged to `stdout` from the SUT. These warnings are expected to happen with some inputs and clutter the fuzzer output logs. They can be optionally re-enabled for debugging by passing a flag o the Python interpreter command line or setting the `PYTHONWARNINGS` environment variable.
DaveLak
deleted the
fix-fuzz-submodule-expected-exceptions-handling
branch
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters