gltfpack: Implement end-to-end fuzzing #625
Merged
Conversation
This file contains 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
While individual components of gltfpack like cgltf or mesh encoders have their own dedicated fuzzers, gltfpack has a lot of code that can be difficult to validate. We would expect that gltfpack is resistant to invalid inputs (with the exception, perhaps, of .obj inputs where fast_obj, the library we use, is currently not fuzz safe). This change implements a in-memory GLB loading flow (parseGlb) and an in-memory fuzzer; we disable all file I/O by using NULL paths, and otherwise share all the same processing code with the exception of final buffer writing.
Note that the dictionary doesn't contain a lot of glTF extensions but it's not clear if we need this, because LLVM libFuzzer uses a mutator that uses strings from the binary in addition to supplied dictionary data. The GLB seed is taken from glTF-Sample-Assets BoxTextured, and is simultaneously reasonably small and covers all the basic features so it's a good candidate to use for a seed.
We technically do this validation during mesh processing, but it's better to flag any out of bounds indices earlier.
We currently have a limit of 16 on some stream based processing algorithms, and it's possible with custom attributes to reach a limit of 16, so for now we just drop extra streams.
To make sure that we don't spend too much time fuzzing the cgltf parser, we only add the files to the corpus if the parsing succeeded. As the comment explains, this is a tradeoff and it's not fully clear what is optimal here, but for now this seems to work okay.
This doesn't touch the top-level gltfpack executable which makes it easier to work on gltfpack while the fuzzer is working, and launches the fuzzer automatically.
|
This PR originally contained a few fixes to cgltf validation but I've extracted them into upstream PRs: jkuhlmann/cgltf#233 jkuhlmann/cgltf#234 jkuhlmann/cgltf#235. Once they get merged this PR should result in a fairly clean fuzzing run: a couple minor problems still remain, and there's some alignment validation missing that results in UBSAN failures (which this change doesn't enable for fuzzing config) but things seem to generally be in a good shape, at least with the default setting set. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
While individual components of gltfpack like cgltf or mesh encoders have
their own dedicated fuzzers, gltfpack has a lot of code that can be
difficult to validate. We would expect that gltfpack is resistant to
invalid inputs (with the exception, perhaps, of .obj inputs where
fast_obj, the library we use, is currently not fuzz safe).
This change implements a in-memory GLB loading flow (parseGlb) and an
in-memory fuzzer; we disable all file I/O by using NULL paths, and
otherwise share all the same processing code with the exception of final
buffer writing.
This is work in progress as fuzzing issues are being discovered and fixed.