-
Files
- .gitignore
- Makefile.am
- README.md
- fuzz.c
- fuzz.h
- genSeed.c
- html.c
- html.dict
- html.options
- regexp.c
- regexp.dict
- regexp.options
- schema.c
- schema.dict
- schema.options
- static_seed/
- testFuzzer.c
- uri.c
- uri.options
- valid.c
- valid.options
- xinclude.c
- xinclude.options
- xml.c
- xml.dict
- xml.options
- xpath.c
- xpath.dict
- xpath.options
-
Properties
-
README.md
-
libFuzzer instructions for libxml2
Set compiler and options. Make sure to enable at least basic optimizations to avoid excessive stack usage. Also enable some debug output to get meaningful stack traces.
export CC=clang export CFLAGS=" \ -O1 -gline-tables-only \ -fsanitize=fuzzer-no-link,address,undefined \ -fno-sanitize-recover=all \ -DFUZZING_BUILD_MODE_UNSAFE_FOR_PRODUCTION"Other options that can improve stack traces:
-fno-omit-frame-pointer -fno-inline -fno-optimize-sibling-calls (disables tail call optimization)Build libxml2 with instrumentation:
./configure --without-python makeRun fuzzers:
make -C fuzz fuzz-xmlMalloc failure injection
Most fuzzers inject malloc failures to cover code paths handling these errors. This can lead to surprises when debugging crashes. You can set the macro XML_FUZZ_MALLOC_ABORT in fuzz/fuzz.c to make the fuzz target abort at the malloc invocation which would fail. This tells you if and where a malloc failure was injected.
Some fuzzers also test whether malloc failures are reported. To debug failures which aren’t reported, it’s helpful to enable XML_FUZZ_MALLOC_ABORT to see which allocation failed. Debugging failures which are erroneously reported can be harder. If the report goes through xmlRaiseMemoryError, you can abort() there to get a stack trace.