When reproducing, use slightly lower limits on heap and stack size so
that minimal changes to fuzz targets, fuzzer and runtime do not cause
memory issues to fail to reproduce.
Prior to this change, native library loading failed for
two reasons:
1. Loading from current working directory instead of the fuzzer's
directory.
2. Using ASAN_OPTIONS=handle_segv=2.
Fix these issues by doing the following.
1. Adding the fuzzer's directory to LD_LIBRARY_PATH instead of "."
2. Specifying handle_segv=1 in ASAN_OPTIONS.
Related: https://github.com/google/oss-fuzz/issues/5178
This is a speculative fix for an issue we've seen where the class
fails to load.
A simpler approach I did not use is cd-ing into $this_dir. I didn't
use this approach because it will break things if relative paths
are passed to the fuzzer by ClusterFuzz.
The other reason that I think could be responsible for the missing
class issues is not unpacking the zipfile fully.
json-sanitizer uses Maven and has no native dependencies.
The build file is loosely divided into two parts. The first part is
project-specific, the second one can serve as a template for JVM fuzz
targets without native dependencies.
The following three fuzz targets are added to OSS-Fuzz and can later be
moved into the json-sanitizer tree:
* DenylistFuzzer verifies that the output of json-sanitizer never
contains certain substrings that can lead to HTML or XML injections.
* IdempotenceFuzzer verifies that json-sanitizer is idempotent.
* ValidJsonFuzzer verifies that the output of json-sanitizer is valid
JSON by passing it into gson.
Fabian Meumertzheim