Eric Campbell 6 min read Engineering

Fuzz Testing: Automated Input Generation

Fuzz testing throws garbage at your code until something breaks. That's the blunt description, but it undersells the technique's power. Fuzzing automatically generates thousands or millions of...

Key Insights

  • Fuzz testing automatically generates millions of malformed inputs to discover edge cases and security vulnerabilities that manual testing and code review consistently miss—it’s how major projects like Chrome, Firefox, and the Linux kernel find critical bugs before attackers do.
  • Coverage-guided fuzzers like AFL++ and libFuzzer use instrumentation feedback to intelligently mutate inputs toward unexplored code paths, making them exponentially more effective than random input generation.
  • Modern fuzzing extends far beyond C/C++: Go, Rust, and Python all have mature fuzzing ecosystems that integrate directly with their standard testing frameworks and package managers.

Introduction to Fuzz Testing

Fuzz testing throws garbage at your code until something breaks. That’s the blunt description, but it undersells the technique’s power. Fuzzing automatically generates thousands or millions of semi-random inputs, feeding them to your program and watching for crashes, hangs, or unexpected behavior.

The technique has an impressive track record. Google’s OSS-Fuzz project has found over 10,000 vulnerabilities in critical open-source software. Security researchers routinely use fuzzers to discover buffer overflows, integer overflows, use-after-free bugs, and logic errors that evade code review and traditional testing.

Why does fuzzing work when other testing methods fail? Human testers think in terms of valid inputs and expected edge cases. Fuzzers don’t think—they explore. They’ll send your JSON parser a 50MB file of null bytes, or your image decoder a valid header followed by random garbage. They find the inputs you’d never imagine.

Types of Fuzzers

Fuzzers fall into two main categories based on how they generate inputs.

Mutation-based fuzzers start with valid sample inputs (a corpus) and randomly modify them—flipping bits, inserting bytes, deleting chunks, or splicing files together. This approach works well when you have good seed inputs and the format has some structure the fuzzer can accidentally preserve.

Generation-based fuzzers build inputs from scratch using a grammar or protocol specification. They’re more complex to set up but generate structurally valid inputs that penetrate deeper into parsing logic.

The more important distinction is between dumb and smart fuzzers:

Dumb fuzzers generate inputs blindly without feedback. They’re simple but inefficient—most generated inputs exercise the same code paths repeatedly.

Coverage-guided fuzzers instrument the target binary to track which code paths each input exercises. When an input reaches new code, the fuzzer saves it and mutates it further. This feedback loop makes coverage-guided fuzzers dramatically more effective.

The major coverage-guided fuzzers you should know:

  • AFL++: The actively-maintained successor to AFL, with advanced mutation strategies and excellent performance
  • libFuzzer: LLVM’s in-process fuzzer, tightly integrated with Clang sanitizers
  • Honggfuzz: Google’s fuzzer with hardware-based coverage feedback support

Setting Up Your First Fuzzer

Let’s integrate libFuzzer with a simple C project. LibFuzzer requires you to write a fuzz target—a function that takes arbitrary bytes and feeds them to your code.

Here’s a basic fuzz target for a hypothetical URL parser:

// fuzz_url_parser.c
#include <stdint.h>
#include <stddef.h>
#include <string.h>

// Your library's header
#include "url_parser.h"

int LLVMFuzzerTestOneInput(const uint8_t *data, size_t size) {
    // Null-terminate the input for string functions
    char *input = malloc(size + 1);
    if (!input) return 0;
    
    memcpy(input, data, size);
    input[size] = '\0';
    
    // Call the function under test
    url_t *parsed = parse_url(input);
    
    // Clean up
    if (parsed) {
        free_url(parsed);
    }
    free(input);
    
    return 0;
}

The function signature is fixed: libFuzzer calls LLVMFuzzerTestOneInput with random byte sequences. Your job is to transform those bytes into something your code consumes and handle the result without leaking resources.

Build with Clang, enabling fuzzing and sanitizers:

CC = clang
CFLAGS = -g -O1 -fno-omit-frame-pointer
FUZZ_FLAGS = -fsanitize=fuzzer,address,undefined
LIB_SRC = url_parser.c

# Build the fuzz target
fuzz_url_parser: fuzz_url_parser.c $(LIB_SRC)
	$(CC) $(CFLAGS) $(FUZZ_FLAGS) -o $@ $^

# Create corpus directory and run
fuzz: fuzz_url_parser
	mkdir -p corpus/url_parser
	./fuzz_url_parser corpus/url_parser

# Run with specific options
fuzz-ci: fuzz_url_parser
	mkdir -p corpus/url_parser
	./fuzz_url_parser corpus/url_parser -max_total_time=300 -jobs=4

The -fsanitize=fuzzer flag links libFuzzer. The address and undefined sanitizers catch memory errors and undefined behavior that might not cause immediate crashes. Run the fuzzer, and it will generate inputs, saving interesting ones to the corpus directory.

Fuzzing in Modern Languages

Modern languages have embraced fuzzing with native tooling support.

Go Fuzzing

Go 1.18 added built-in fuzz testing to the standard testing package. Here’s a fuzz test for a JSON configuration parser:

// config_test.go
package config

import (
    "testing"
    "unicode/utf8"
)

func FuzzParseConfig(f *testing.F) {
    // Seed the corpus with valid examples
    f.Add([]byte(`{"name": "test", "timeout": 30}`))
    f.Add([]byte(`{"name": "", "timeout": 0}`))
    f.Add([]byte(`{}`))
    
    f.Fuzz(func(t *testing.T, data []byte) {
        // Skip invalid UTF-8 to focus on logic bugs
        if !utf8.Valid(data) {
            return
        }
        
        cfg, err := ParseConfig(data)
        if err != nil {
            // Parsing errors are expected for random input
            return
        }
        
        // If parsing succeeds, validate invariants
        if cfg.Timeout < 0 {
            t.Errorf("negative timeout should be rejected: %d", cfg.Timeout)
        }
        
        // Round-trip test: serialize and re-parse
        serialized, err := cfg.Serialize()
        if err != nil {
            t.Fatalf("failed to serialize valid config: %v", err)
        }
        
        cfg2, err := ParseConfig(serialized)
        if err != nil {
            t.Fatalf("failed to re-parse serialized config: %v", err)
        }
        
        if cfg.Name != cfg2.Name || cfg.Timeout != cfg2.Timeout {
            t.Errorf("round-trip mismatch: %+v vs %+v", cfg, cfg2)
        }
    })
}

Run with go test -fuzz=FuzzParseConfig. Go’s fuzzer is coverage-guided and integrates with the standard test runner.

Rust Fuzzing

Rust uses cargo-fuzz, which wraps libFuzzer. Initialize fuzzing in your project:

cargo install cargo-fuzz
cargo fuzz init
cargo fuzz add parse_input

Then write your fuzz target:

// fuzz/fuzz_targets/parse_input.rs
#![no_main]

use libfuzzer_sys::fuzz_target;
use my_crate::parse_input;

fuzz_target!(|data: &[u8]| {
    // Try to interpret as UTF-8 string
    if let Ok(s) = std::str::from_utf8(data) {
        // Ignore errors—we're looking for panics and UB
        let _ = parse_input(s);
    }
});

For structured fuzzing, use arbitrary to derive random instances of your types:

// fuzz/fuzz_targets/structured_fuzz.rs
#![no_main]

use libfuzzer_sys::fuzz_target;
use arbitrary::Arbitrary;

#[derive(Arbitrary, Debug)]
struct FuzzInput {
    name: String,
    values: Vec<i32>,
    flag: bool,
}

fuzz_target!(|input: FuzzInput| {
    let _ = my_crate::process_input(&input.name, &input.values, input.flag);
});

Run with cargo fuzz run parse_input. Crashes appear in fuzz/artifacts/.

Coverage-Guided Fuzzing Explained

Coverage-guided fuzzers work through a feedback loop:

  1. Generate or mutate an input
  2. Execute the target with instrumentation tracking code coverage
  3. If the input reached new code paths, add it to the corpus
  4. Repeat, prioritizing mutations of inputs that found new coverage

This approach means the fuzzer learns the input format implicitly. Feed it one valid JSON document, and it will eventually discover that {, }, :, and " are special characters that unlock new code paths.

View coverage to understand what your fuzzer has explored:

# Generate coverage report with libFuzzer
./fuzz_url_parser corpus/url_parser -runs=0 -dump_coverage=1

# With AFL++, use afl-cov
afl-cov -d output/ --coverage-cmd "./url_parser AFL_FILE" --code-dir ./src/

Corpus management matters. Periodically minimize your corpus to remove redundant inputs:

# libFuzzer corpus minimization
mkdir corpus_min
./fuzz_url_parser -merge=1 corpus_min corpus/url_parser

A smaller corpus means faster startup and more focused mutation.

Integrating Fuzzing into CI/CD

Fuzzing needs time to be effective—minutes to hours, not seconds. This doesn’t fit the typical CI model of fast feedback. You have several options:

Short smoke tests in CI: Run fuzzers for 60-300 seconds on every PR. You won’t find deep bugs, but you’ll catch regressions and obvious issues.

Continuous fuzzing infrastructure: Run fuzzers 24/7 on dedicated machines. OSS-Fuzz provides this free for open-source projects. For private code, consider ClusterFuzz or self-hosted solutions.

Regression testing with crash corpus: Save every crash as a test case. Run these fixed inputs in CI to prevent regressions:

# .github/workflows/fuzz.yml
name: Fuzz Testing
on: [push, pull_request]

jobs:
  fuzz-regression:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Build fuzz targets
        run: make fuzz_url_parser
      - name: Run regression tests
        run: ./fuzz_url_parser crash_corpus/ -runs=0
        
  fuzz-short:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Build and fuzz
        run: |
          make fuzz_url_parser
          timeout 120 ./fuzz_url_parser corpus/ || true          
      - uses: actions/upload-artifact@v4
        if: failure()
        with:
          name: crash-artifacts
          path: crash-*

Analyzing and Triaging Crashes

When a fuzzer finds a crash, you get a file containing the input that triggered it. Your workflow:

  1. Reproduce: Confirm the crash is deterministic
  2. Minimize: Reduce the input to its essential trigger
  3. Diagnose: Use sanitizer output to understand the root cause
  4. Fix: Patch the code
  5. Verify: Confirm the minimized input no longer crashes
#!/bin/bash
# reproduce_and_minimize.sh

CRASH_FILE=$1
TARGET=./fuzz_url_parser

# Reproduce
echo "Reproducing crash..."
$TARGET $CRASH_FILE
if [ $? -eq 0 ]; then
    echo "Crash not reproduced"
    exit 1
fi

# Minimize
echo "Minimizing..."
mkdir -p minimized
$TARGET -minimize_crash=1 -exact_artifact_path=minimized/min_crash $CRASH_FILE

echo "Minimized crash saved to minimized/min_crash"
echo "Original size: $(wc -c < $CRASH_FILE)"
echo "Minimized size: $(wc -c < minimized/min_crash)"

# Show sanitizer output
echo "Sanitizer report:"
$TARGET minimized/min_crash 2>&1 | head -50

Sanitizer output tells you exactly what went wrong. AddressSanitizer shows heap buffer overflows with allocation stack traces. UndefinedBehaviorSanitizer catches signed integer overflow and null pointer dereferences. MemorySanitizer finds reads of uninitialized memory.

Once fixed, add the minimized crash to your regression corpus. It becomes a permanent test case ensuring the bug never returns.

Fuzzing isn’t a replacement for other testing—it’s a complement. Unit tests verify expected behavior. Fuzz tests discover unexpected inputs. Together, they build confidence that your code handles the real world’s chaos.

Liked this? There's more.

Every week: one practical technique, explained simply, with code you can use immediately.