fix(fuzzing): correct imports in the intermediate report fuzzing harness #5257
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
It's theoretically an autogenerated file, however it's checked-in anyway, plus it's unclear whether there's a protoc-level solution and investigating that would take inordinate amount of time compared to this one-liner, given the overall fragility of the fuzzing setup.
Tested via GH actions in my fork, example of a successful run (with the fix for #5244 also applied).
Fixes #5140.
On a side note,
atheris
seems to be having troubles with getting maintainer time, and will fail to compile for Python 3.12+. There are also problems with Abseil (second-order dependency) building on GCC 13+, that may come up at some point too. That adds to the fragility I mentioned above.Longer story based on the investigation notes if you're interested
This particular fuzzing script is unique among the set, as it imports one protobuf-generated module, which in turn imports another one (
cve_data_pb2
). All other ones are one-level only. The specific format of the import generated byprotoc
+ some peculiarity of how theatheris.Fuzz()
is running the whole process leads to two distinct invocations of the import. One works fine, because the package is well-defined, and another one fails, because it's not. The stack traces I've added are below for illustration.