Fuzzing Go Expert

The inner f.Fuzz callback signature can use typed parameters instead of []byte when the target expects structured input:

f.Fuzz(func(t *testing.T, s string, n int, b bool) {
    _ = ProcessRecord(s, n, b)
})

Building in OSS-Fuzz

Use the compile_native_go_fuzzer helper in build.sh. It takes the package import path, the function name, and the output binary name:

# build.sh
cp $SRC/fuzz_test.go ./          # copy harness into the module if needed
printf "package mypkg\nimport _ \"github.com/AdamKorcz/go-118-fuzz-build/testing\"\n" \
    > register.go                # required registration shim
go mod tidy
compile_native_go_fuzzer github.com/owner/repo/pkg FuzzMyTarget fuzz_my_target

For projects with multiple packages or multiple fuzz targets repeat the call:

compile_native_go_fuzzer github.com/owner/repo/pkg1 FuzzFoo fuzz_foo
compile_native_go_fuzzer github.com/owner/repo/pkg2 FuzzBar fuzz_bar

Seed corpus and dictionaries

• Seed corpus entries go in $OUT/<fuzzer_name>_seed_corpus/ as individual files, or as a zip at $OUT/<fuzzer_name>_seed_corpus.zip.
• Dictionaries go in $OUT/<fuzzer_name>.dict as plaintext token files.
• Alternatively, add seeds directly via f.Add(...) in the harness — these are compiled in and used as the initial corpus.

Characteristics of good Go fuzzing harnesses

1. Targets attack surface: focus on parsers, decoders, protocol handlers, serialisation/deserialisation, and any API that accepts untrusted bytes or strings.
2. Handles expected errors gracefully: wrap calls in error checks and ignore expected error returns. Only genuine panics and unexpected behaviour are findings.
3. Uses typed fuzz parameters when the target is not purely byte-oriented — Go's fuzzer can mutate string, int, bool, float64, etc. directly.
4. Avoids non-determinism: do not use random sources, time, goroutines, or global state that persists between calls.
5. Keeps the callback fast: expensive setup (e.g. parsing config, opening files) belongs outside f.Fuzz(...), not inside the inner function.
6. Provides meaningful seeds: f.Add(...) entries should be valid representative inputs so coverage grows from the start.
7. Does not get stuck: avoid code paths that busy-loop or block on I/O inside the fuzz function.
8. Includes the registration shim: the import _ "github.com/AdamKorcz/go-118-fuzz-build/testing" blank import is required for OSS-Fuzz to hook into native Go fuzzing — never omit it.

What Go fuzzing finds

Go is memory-safe, so the focus shifts from memory-corruption bugs to:

• Panics: index out of range, nil pointer dereference, type assertion failures, stack overflows — any unrecovered panic is a crash.
• Logic bugs: incorrect parsing, silent data corruption, wrong output for valid input.
• Infinite loops / hangs: code that never returns on certain inputs (detected by OSS-Fuzz's timeout).
• Incorrect error handling: code that should return an error but panics instead, or vice versa.

Operational guidelines

• Always validate with:

  python3 infra/helper.py build_fuzzers <project>
  python3 infra/helper.py check_build <project>
  python3 infra/helper.py run_fuzzer <project> <fuzzer_name> -- -max_total_time=30
  

• An instant crash almost always means the harness itself is wrong (e.g. missing error handling, bad seed, wrong package path).
• Run go vet ./... and go build ./... inside the module before wrapping in an OSS-Fuzz build to catch compile errors early.
• When iterating locally clone the upstream repo and switch the Dockerfile from RUN git clone to COPY to avoid network round-trips.
• Document why each entry point was chosen and what class of bugs it may find.