Fuzz a parser and turn crashes into lasting regressions

A fuzzer repeatedly supplies generated or mutated inputs to a program and looks for failures. Coverage-guided fuzzing uses execution feedback to favor inputs that reach new paths. It does not know what your file format means unless the harness or assertions express those rules. A parser that silently accepts malformed data can be wrong without crashing, while a correct parser should reject ordinary malformed input without terminating the process.

The format here is deliberately small: two unsigned big-endian bytes encode a payload length from 0 through 4096, followed by exactly that many bytes and no trailing data. For 00 08 41 42, the header declares eight bytes but only two remain. A parser that copies eight bytes from data+2 reads beyond the buffer. It must first establish a two-byte header, then validate the declared maximum and exact remaining size before accessing the payload. Checking only the destination buffer size does not prove the source has enough bytes.

The complete Python program below is a bounded parser regression and mutation exercise, requiring only Python 3. Save it as parser_demo.py and run python3 parser_demo.py. It tests fixed boundary cases, exhaustively checks two-byte headers for a fixed payload and separately applies one-byte mutations, and verifies the meaning of every accepted result. It is deliberately not described as coverage-guided native fuzzing: Python's managed byte slices and this enumerator have different failure detection from C++ instrumentation.

For a native production parser, write a harness that implements LLVMFuzzerTestOneInput and calls the same parser used by the application. Build both harness and parser with coverage and sanitizer instrumentation, such as AddressSanitizer, record the compiler version and flags, and give the process input-size, time and memory budgets. Keep iteration state independent: free results, reset mutable globals and avoid filesystem or network effects. Seed with minimal valid records and truncations so the engine can reach payload handling instead of spending every iteration on an early magic-header rejection, and add a dictionary of format tokens when the format has tagged fields.

# Save as parser_demo.py; run: python3 parser_demo.py
import random

def parse(data):
    if len(data) < 2:
        return None
    size = int.from_bytes(data[:2], 'big')
    if size > 4096 or size != len(data) - 2:
        return None
    return data[2:]

fixtures = [
    (b'', None), (b'\x00', None), (b'\x00\x00', b''),
    (b'\x00\x02AB', b'AB'), (b'\x00\x08AB', None),
    (b'\x00\x02A', None), (b'\x00\x01AB', None),
    ((4096).to_bytes(2, 'big') + b'A' * 4096, b'A' * 4096),
    ((4097).to_bytes(2, 'big') + b'A' * 4097, None),
]
for data, expected in fixtures:
    assert parse(data) == expected

rng = random.Random(7)
seeds = [data for data, _ in fixtures[:7]]
checked = 0
for first in range(256):
    for second in range(256):
        data = bytes([first, second]) + b'AB'
        out = parse(data)
        if out is not None:
            assert out == b'AB' and data[:2] == b'\x00\x02'
        checked += 1
for _ in range(2000):
    data = bytearray(rng.choice(seeds))
    if data:
        data[rng.randrange(len(data))] = rng.randrange(256)
    out = parse(bytes(data))
    if out is not None:
        assert len(out) <= 4096
        assert len(out) == int.from_bytes(data[:2], 'big')
        assert len(data) == len(out) + 2
    checked += 1
print(f'PASS: 9 boundary fixtures and {checked} generated inputs')

The C file below contains the repaired parser and its libFuzzer harness. The harness adds a semantic oracle: any accepted record must have exactly the declared length, so a parser that silently ignored trailing bytes would abort even though nothing overflowed. Built with clang 21 and -fsanitize=fuzzer,address,undefined, it ran 89 million inputs in 60 seconds without a failure. The same harness pointed at the original excerpt failed on the first, empty input with a heap-buffer-overflow reading data[1]; after adding only the header check, it found the record 00 02, a declared two-byte payload with no bytes, as a memcpy over-read within seconds, and -minimize_crash=1 kept it at two bytes.

libFuzzer's original authors have moved to Centipede, whose code now lives in the Google FuzzTest repository, and LLVM describes libFuzzer as receiving bug fixes but no major new features. A harness written to this entry point is not tied to it: AFL++ builds it with its own compiler wrappers, and OSS-Fuzz and ClusterFuzzLite run it continuously. The native-memory-safety project below applies the same sanitizer workflow to a parser you repair yourself, and /domains/appsec/platform-security/memory-safety-c-cpp/ covers the defect classes the sanitizers report.

// fuzz_record.c: the repaired parser and a libFuzzer harness in one file.
// Build: clang -g -O1 -fsanitize=fuzzer,address,undefined fuzz_record.c -o fuzz_record
// Run:   mkdir -p corpus && ./fuzz_record -max_len=4100 -max_total_time=60 corpus/
#include <stddef.h>
#include <stdint.h>
#include <stdlib.h>
#include <string.h>

#define MAX_PAYLOAD 4096

// Returns the payload length, or -1 for a malformed record. out holds MAX_PAYLOAD bytes.
int parse_record(const uint8_t *data, size_t size, uint8_t *out) {
    if (size < 2) return -1;                 // the header must exist before it is read
    size_t length = ((size_t)data[0] << 8) | data[1];
    if (length > MAX_PAYLOAD) return -1;     // the format maximum
    if (length != size - 2) return -1;       // exact remaining bytes; size >= 2 here
    memcpy(out, data + 2, length);
    return (int)length;
}

// The same entry point works with AFL++, honggfuzz, OSS-Fuzz and ClusterFuzzLite.
int LLVMFuzzerTestOneInput(const uint8_t *data, size_t size) {
    uint8_t out[MAX_PAYLOAD];
    int n = parse_record(data, size, out);
    // Semantic oracle: an accepted record means exactly what its header says.
    if (n >= 0 && (size != (size_t)n + 2 || n != ((data[0] << 8) | data[1]))) abort();
    return 0;
}

Memory-safe languages still need fuzzing for panics, excessive allocation, hangs and wrong results, and unsafe FFI needs its ownership and length assumptions checked on both sides of the boundary (/domains/appsec/platform-security/rust-unsafe-ffi/). Go has native fuzzing since 1.18: the test below seeds the exercise records and checks the same oracle. Run for 60 seconds with Go 1.27, it executed about 48 million inputs without a failure, and against a version that accepted trailing data it failed within a fraction of a second on the seed 00 01 41 42, saving the input under testdata/fuzz as a regression.

package record

import (
	"bytes"
	"encoding/binary"
	"testing"
)

// Run: go test -fuzz=FuzzParse -fuzztime=60s
func FuzzParse(f *testing.F) {
	for _, seed := range [][]byte{{}, {0}, {0, 0}, {0, 2, 'A', 'B'}, {0, 8, 'A', 'B'}, {0, 1, 'A', 'B'}} {
		f.Add(seed)
	}
	f.Fuzz(func(t *testing.T, data []byte) {
		out, err := Parse(data)
		if err != nil {
			return
		}
		// Semantic oracle: an accepted record means exactly what its header says.
		if len(out) > maxPayload || len(data) != len(out)+2 ||
			int(binary.BigEndian.Uint16(data)) != len(out) || !bytes.Equal(out, data[2:]) {
			t.Fatalf("accepted %x as %x", data, out)
		}
	})
}

When a native run reports a fault, preserve the exact input bytes, source revision, binary and compiler configuration, sanitizer report and reproduction command. Reproduce with that single input before assuming every crash is the same defect. Minimization removes bytes while preserving the same failure, making the missing precondition visible. The tiny failing record 00 08 41 42 already explains an eight-byte request from a two-byte source payload.

Fix the invariant, not the specimen. Special-casing 00 08 or requiring four total bytes would leave empty, one-byte and larger truncated inputs unresolved. Check header availability before reading either length byte. After that check, comparing length to size - 2 avoids addition overflow patterns common in native size arithmetic. Enforce the format maximum separately, then copy only after all conditions hold. Re-run the minimized fixture, ordinary successful records and nearby boundaries, including integer-overflow and zero-length cases where relevant; keep the reproducer as a lasting regression even after the fuzz corpus changes.

The supplied program's PASS result means nine named cases and 67,536 generated inputs satisfied these assertions. It does not mean all possible inputs or all production parsers are safe. The exhaustive loop covers every two-byte length for a fixed AB payload, while the mutation loop changes only small supplied seeds. It does not explore native memory ownership, streaming state, Unicode decoding or archive nesting because this format contains none of them.

Likewise, native coverage and execution count describe exercised code, not a proof of security. Track whether meaningful format states were reached, and add semantic or differential oracles when crashes alone cannot identify wrong results. Limit allocation before attempting expensive work. A timeout can signal a complexity defect rather than a memory error. Group failures by cause and assess shipped exposure separately from the mechanics of reproducing a crash in an isolated harness.

Coverage-guided fuzzing finds exactly this class of bug. CVE-2022-37434 was a heap buffer over-read and overflow in zlib's inflate when processing a large gzip-header extra field, the kind of input a fuzzer reaches quickly. Fuzzing the parser with sanitizers enabled would have caught it before release.

The parser contract includes semantic properties beyond memory safety. If the parser returns only the first declared bytes while ignoring trailing input, it may never crash but still accept E incorrectly. If it returns the length header as part of the payload, a memory sanitizer can remain silent while the decoded value is wrong. Add assertions about accepted structure and exact output; the supplied program checks both length and payload for its exhaustive AB family.

Differential testing can compare independent implementations of the same documented format, but disagreement is a question to investigate, not automatic proof that one chosen reference is correct. Keep the specification as the authority and minimize the differing input. For stateful parsers, reset or explicitly model state between iterations, then include multi-message sequences when the production interface carries state. A stateless harness cannot reveal a bug that requires a prior message to set a mode.

Native sanitizer reports also need careful triage. A use-after-free and a source-buffer over-read may produce failures at the same copy function but have different causes and fixes. Preserve allocation and lifetime evidence, not just the top stack frame. After repair, keep the smallest meaningful regression and resume broader fuzzing to look for adjacent faults. More CPU time helps only when the harness reaches relevant code and the oracle can recognize the failures that matter.

Sources & further reading

The standards, specifications and documentation behind the guidance above. Each is the evidence for a claim on this page; consult it for detail beyond the defaults and versions listed here.

1. LLVM libFuzzer documentation
2. Clang AddressSanitizer documentation
3. AFL++ documentation
4. Google FuzzTest
5. OSS-Fuzz documentation
6. ClusterFuzzLite documentation
7. Go: fuzzing
8. NVD: CVE-2022-37434, heap overflow in zlib inflate

Reference information

Tags

Input validation and parsingMemory safetySecurity testingC, C++ and Rust

SDLC phase

Testing

Role

DevelopersAppSec engineers

ASVS 5.0.0 requirements

v5.0.0-1.4.1 · v5.0.0-1.4.2

CAPEC attack patterns

• CAPEC-28 at MITRE

Download this guide as Markdown

Continue exploring