Fuzzing for Bugs

What fuzzing finds

Fuzzing targets the boundary where untrusted input meets your code — parsers, decoders, request handlers. It excels at the bugs humans skip past:

• Trust-the-length bugs — a length field that slices past the buffer (panic in Go; overflow in C).
• Off-by-ones and bounds — empty input, one byte, the maximum value of an int.
• Infinite loops / pathological input — a “zip bomb” of nested structures, catastrophic regex backtracking.
• Logic crashes — nil derefs and type assertions on malformed data.

graph LR
SEED["seed corpus<br/>(valid inputs)"] --> MUT["mutate<br/>(flip, trim, grow)"]
MUT --> RUN["run target<br/>(under recover)"]
RUN -->|panic!| SAVE["save crashing input<br/>→ regression test"]
RUN -->|new coverage| KEEP["keep & mutate more"]
RUN -->|nothing new| MUT

See it: a mutation fuzzer that finds a real bug

parseFrame has the classic trust-the-length bug. This little fuzzer mutates a valid seed until it discovers an input that crashes it — and reports the exact bytes. It runs here (seeded RNG, so the output is deterministic):

package main

import (
"fmt"
"math/rand"
)

// parseFrame trusts a 1-byte length prefix — the bug a fuzzer will find.
func parseFrame(b []byte) []byte {
n := int(b[0])      // panics on empty input
return b[1 : 1+n]   // panics when 1+n > len(b): trust-the-length
}

// run the target, converting a panic into a reported crash.
func tryParse(b []byte) (crashed bool, msg string) {
defer func() {
	if r := recover(); r != nil {
		crashed, msg = true, fmt.Sprint(r)
	}
}()
parseFrame(b)
return false, ""
}

func main() {
rng := rand.New(rand.NewSource(42)) // fixed seed → deterministic
seed := []byte{2, 'h', 'i'}         // a valid frame: len=2, data "hi"

for i := 0; i < 10000; i++ {
	// Mutate a copy of the seed: tweak the length byte and/or trim.
	in := append([]byte(nil), seed...)
	in[0] = byte(rng.Intn(256))   // attacker-controlled length
	if rng.Intn(2) == 0 && len(in) > 1 {
		in = in[:1+rng.Intn(len(in))] // sometimes truncate the data
	}
	if crashed, msg := tryParse(in); crashed {
		fmt.Printf("CRASH after %d inputs\n", i+1)
		fmt.Printf("  input:  %v\n", in)
		fmt.Printf("  panic:  %s\n", msg)
		return
	}
}
fmt.Println("no crash found")
}

The fuzzer hands parseFrame a length byte that’s larger than the data and the slice expression panics — a denial-of-service bug in Go, a memory-corruption bug in C. A human writing test cases rarely thinks to try “length says 200, data is 2 bytes.” The fuzzer tries it in milliseconds.

Go’s built-in coverage-guided fuzzing

Hand-rolled mutation is blind. Since Go 1.18 the toolchain ships coverage-guided fuzzing — it instruments your code, keeps inputs that reach new branches, and minimizes any crash it finds into a saved regression test. The harness is a normal test (fenced — go test -fuzz can’t run in the playground):

func FuzzParseFrame(f *testing.F) {
	f.Add([]byte{2, 'h', 'i'}) // seed corpus
	f.Fuzz(func(t *testing.T, b []byte) {
		parseFrame(b) // a panic here is a failure the fuzzer reports
	})
}

Run it with go test -fuzz=FuzzParseFrame. On a crash, Go writes the minimized input to testdata/fuzz/FuzzParseFrame/... so it becomes a permanent unit test — fix the bug and the corpus guards against regressions forever. See fuzzing in the stdlib track for the full workflow.

Fuzzing is your best defense

See also

• Fuzzing (stdlib track) — the full go test -fuzz workflow and corpus management.
• Input validation & injection defense — fixing the bugs fuzzing finds.
• HTTP recon — finding the input boundaries to fuzz.
• Building security tools — wrapping a fuzzer in a tool.

Next: reading the raw bytes on the wire — packet analysis.

Related topics