Coverage-Guided Dynamic Analysis — Interview Level¶

Roadmap: Dynamic Analysis & Sanitizers → Coverage-Guided Dynamic Analysis A fuzzing interview rarely asks "what is a fuzzer." It asks "you fuzzed for a week and found nothing — what's wrong," and then watches whether you can separate the input generator from the oracle, name why coverage feedback exists, and explain why a crash without a sanitizer is a crash you'll never see. This page is the question bank, with model answers and a note on what each question is really probing.

Table of Contents¶

1. How to Use This Page
2. Introduction
3. Prerequisites
4. Fundamentals
5. Mechanism
6. Oracles — The Differentiator
7. Practice at Scale
8. Limits
9. Scenario & Debugging
10. Rapid-Fire
11. Red Flags / Green Flags
12. Cheat Sheet
13. Summary
14. Further Reading
15. Related Topics

How to Use This Page¶

Each question carries three things: Q (the prompt), what the interviewer is really testing, and A (a model answer at the depth a strong candidate gives). Don't memorize the answers — internalize the distinctions they keep returning to:

• generator vs oracle (what makes a weird input vs what decides the input was bad)
• coverage vs correctness (you reached a line vs the line is right)
• shallow vs deep bugs (one input triggers it vs you need a sequence of states)
• finding a bug vs keeping it found (a crash vs a permanent regression test)

Nearly every question in this bank is one of those four distinctions wearing a costume. The candidates who do well are the ones who name the distinction before reaching for a flag. The single sentence that separates a senior answer from a junior one is: "coverage without an oracle finds nothing."

Introduction¶

Coverage-guided fuzzing is the highest-yield automated bug-finding technique in the practitioner's toolkit, and it is also the one most often misunderstood. People treat it as "throw random bytes at the program." It is the opposite: a feedback loop that measures which inputs reach new code and breeds from those, turning a blind search into a directed one. But the search is only half the system. The other half — the part interviews probe hardest — is the oracle: the thing that decides an input revealed a defect. A fuzzer that maximizes coverage with no oracle is a very expensive way to confirm your program doesn't crash. Pair it with a sanitizer and the same run finds heap overflows, use-after-frees, integer UB, and uninitialized reads. The fuzzer is the input generator; the sanitizer is the oracle; together they are the killer combination this topic is built around.

Prerequisites¶

You'll answer these questions far better if you're solid on:

• Sanitizers as oracles — what ASan, UBSan, and MSan detect, and the constraint that ASan and MSan can't be combined. See 01 — AddressSanitizer and 03 — UndefinedBehaviorSanitizer.
• Code coverage — edge vs line vs block coverage, and why coverage is necessary but not sufficient.
• The build pipeline — instrumentation is a compile-time transform (-fsanitize-coverage), so you need to know what the compiler is inserting.
• Testing fundamentals — fuzzing is a member of the test family, adjacent to property-based testing. See Testing.

If "what is a relocation" or "compile vs link" is shaky, the build-systems fundamentals page is upstream of all of this.

Fundamentals¶

Q: What is fuzzing, and what specifically makes it coverage-guided?¶

Testing: Whether you know the distinction that defines the modern technique, or think all fuzzing is random.

A. Fuzzing is feeding a program large volumes of generated input to provoke crashes or detectable misbehavior. Dumb/black-box fuzzing generates inputs with no knowledge of the program — pure random or mutated-from-seed — and gets stuck almost immediately, because hitting a deep branch by chance is astronomically unlikely.

Coverage-guided fuzzing closes a feedback loop. The target is compiled with edge instrumentation so every executed control-flow edge is recorded. The fuzzer runs an input, looks at the coverage signal, and asks: did this input exercise an edge no previous input did? If yes, the input is interesting — it's added to the corpus and used as a base for future mutations. If no, it's discarded. So the corpus accumulates inputs that collectively push deeper into the program, and the search becomes directed by the program's own structure rather than blind. That feedback loop — instrument, run, keep-on-new-edge, mutate — is the whole idea.

Q: Define corpus, seed, and harness.¶

Testing: Vocabulary, and whether you understand the harness is the thing you write.

A. - Seed — a starting input you provide, ideally a small, valid, diverse example of what the target parses (one real PNG, one real JSON). Good seeds skip the fuzzer past the boring "is this even the right format" branches. - Corpus — the evolving set of inputs the fuzzer keeps because each one reached new coverage. It starts as your seeds and grows as the fuzzer discovers interesting inputs. It's the fuzzer's accumulated knowledge; you save it and reuse it across runs. - Harness (or fuzz target) — the function you write that takes a buffer of bytes and feeds it into the code under test. It's the adapter between "here are some bytes" and "call my parser." The harness is where most of the engineering judgment lives: a bad harness fuzzes nothing useful no matter how good the fuzzer is.

Q: Why is "fuzzing + sanitizer" called the killer combination?¶

Testing: The single most important conceptual point — generator vs oracle.

A. Because they're two halves of one system. The fuzzer is the input generator — it's extremely good at producing the weird, malformed, boundary inputs a human would never write. But a fuzzer on its own only detects hard crashes (SIGSEGV, SIGABRT). Plenty of serious memory-safety bugs don't crash on the spot — a heap-buffer-overflow by a few bytes often reads or writes adjacent valid memory and the program sails on, silently corrupted.

The sanitizer is the oracle — it instruments memory operations so that the overflow is caught the instant it happens and turned into a loud, deduplicated abort with a stack trace. So the fuzzer's job is to reach the buggy state; the sanitizer's job is to notice it. Coverage feedback drives reach; the sanitizer drives detection. Run them together and a single campaign surfaces use-after-free, heap/stack overflow, integer overflow, and uninitialized reads — bugs that a fuzzer alone would walk straight past.

Q: Write a minimal libFuzzer harness, and the Go equivalent.¶

Testing: Whether you've actually written one, and whether you know the entry-point contract.

A. libFuzzer calls a function with a fixed signature, repeatedly, with fuzzer-controlled bytes:

// fuzz_parse.c — build: clang -g -fsanitize=fuzzer,address fuzz_parse.c parser.c
#include <stddef.h>
#include <stdint.h>
#include "parser.h"

int LLVMFuzzerTestOneInput(const uint8_t *data, size_t size) {
    // Hand the fuzzer's bytes straight to the code under test.
    parse_config(data, size);   // ASan is the oracle if this corrupts memory
    return 0;                   // non-zero is reserved; always return 0
}

The rules: the function must be reentrant and not crash on valid input, must not exit(), and should be fast (it runs millions of times). -fsanitize=fuzzer,address links libFuzzer and ASan in one binary — generator and oracle together.

Go's native fuzzing wraps the same idea behind the test framework:

// parser_test.go — run: go test -fuzz=FuzzParseConfig
func FuzzParseConfig(f *testing.F) {
    f.Add([]byte(`{"timeout": 30}`)) // a seed
    f.Fuzz(func(t *testing.T, data []byte) {
        ParseConfig(data) // panics or detected races become failures
    })
}

f.Add seeds the corpus; f.Fuzz's closure is the harness. Go's runtime race detector and bounds checks act as built-in oracles, so a Go fuzzer catches panics and data races without a separate sanitizer.

Mechanism¶

Q: How does coverage feedback actually work under the hood?¶

Testing: Whether "coverage-guided" is a slogan or a mechanism you understand.

A. At compile time, instrumentation (-fsanitize-coverage=trace-pc-guard / inline-8bit-counters) inserts a tiny snippet at every edge — every branch target — that bumps a counter in a shared map. After each input runs, the fuzzer compares the post-run map against the cumulative "edges we've seen" set. The loop is:

1. Pick an input from the corpus.
2. Mutate it (bit flips, byte swaps, splices with another corpus entry, insert dictionary tokens, arithmetic on integers).
3. Run the mutated input; read the coverage map.
4. If it hit a new edge (or a new counter bucket), save it to the corpus as a new base. Otherwise discard.
5. Repeat, biasing selection toward inputs that recently produced new coverage.

It's a genetic-algorithm-flavored search where the fitness function is "did you reach somewhere new." Edge coverage (not just line/block) matters because it distinguishes which way a branch went, which is what you need to discover that the else path exists.

Q: What are counter buckets, and why not just track "edge hit / not hit"?¶

Testing: A subtle mechanism detail that separates readers from doers.

A. A pure boolean "this edge was taken" loses information about loops. Code that runs a loop body 1 time vs 1,000 times exercises very different states (off-by-one at the boundary, overflow on the large count), but both are "edge taken." So coverage-guided fuzzers bucket hit counts into coarse ranges — typically 1, 2, 3, 4–7, 8–15, 16–31, 32–127, 128+. Moving an edge from the "3" bucket to the "4–7" bucket counts as new coverage and the input is kept. This lets the fuzzer discover inputs that drive loops to interesting iteration counts without exploding the corpus with every distinct count. It's a cheap approximation of "did the program reach a meaningfully different state."

Q: In-process (libFuzzer) vs fork-server (AFL) execution — what's the trade-off?¶

Testing: Whether you know the two execution models and their failure modes.

A. In-process (libFuzzer) runs the harness as a function call in a single long-lived process — millions of iterations per process. It's extremely fast (no process spawn per input, often 100k+ exec/s for cheap targets) but fragile to global state: if iteration N leaves a static cache dirty or leaks, iteration N+1 is contaminated, and a real crash takes the whole process down so you lose the in-flight state. The harness must be clean and reentrant.

Fork-server (AFL/AFL++) forks a fresh child from a pre-initialized parent for each input (or batch). It's slower per exec but isolated: each input gets a clean process, so global-state bleakage and crashes don't poison subsequent runs. AFL++ supports a persistent mode that mimics libFuzzer's in-process speed when the target is clean. Modern practice (AFL++, libFuzzer-via-FuzzTest) blurs the line, but the trade-off is the timeless one: speed vs isolation.

Q: Your fuzzer can't get past a 4-byte magic header or a checksum. How does the fuzzer itself help?¶

Testing: CMP/compare feedback — the mechanism that beats magic bytes.

A. This is where naive mutation dies: guessing a specific 4-byte constant by random flips is 1-in-4-billion. Modern fuzzers solve the magic-bytes problem with comparison instrumentation (-fsanitize-coverage=trace-cmp, AFL++'s CmpLog / laf-intel). The compiler instruments every comparison so the fuzzer can see the operands: when the code does if (header == 0x89504E47), the fuzzer observes "you compared input bytes against 0x89504E47" and directly stuffs that constant into the input. Big comparisons are also split into byte-wise ones so coverage rewards getting each byte right incrementally, turning a cliff into a staircase.

Checksums are harder — the comparison is computed_crc == stored_crc, and CmpLog only learns the expected value for that input, which changes every mutation. The real fixes are: (1) patch out the check in a fuzz-only build (#ifdef FUZZING), letting the fuzzer past the gate and re-validating crashes against the unpatched build; or (2) a custom mutator that recomputes the checksum after every mutation so inputs stay well-formed.

Q: What is structure-aware fuzzing and when do you need it?¶

Testing: Whether you know byte-level mutation has a ceiling for structured inputs.

A. For deeply structured inputs — a programming language, a protobuf message, a TLS handshake — random byte mutation spends ~all its time producing inputs rejected at the first parse stage, never reaching the interesting semantic logic. Structure-aware fuzzing has the fuzzer mutate a typed representation instead of raw bytes. Tools: libprotobuf-mutator (mutate a protobuf, serialize it, feed it in), Go's typed f.Fuzz(func(t, a int, b string){...}) arguments, or a custom grammar. The fuzzer's mutations now stay structurally valid by construction, so coverage goes into the logic instead of bouncing off the parser. Rule of thumb: if the format has a strict grammar or a parse-then-process split, reach for structure-aware fuzzing; if it's a byte-oriented parser (image, font, archive), raw byte mutation plus a good dictionary usually suffices.

Oracles — The Differentiator¶

Q: What's an oracle, and why is it the part that actually matters?¶

Testing: The central thesis of the topic.

A. An oracle is the mechanism that decides a given execution was wrong. The fuzzer generates inputs; the oracle renders the verdict. This is the differentiator because coverage without an oracle finds nothing — you can achieve 100% coverage and discover zero bugs if nothing is watching for incorrect behavior. The fuzzer's only built-in oracle is "did the process crash," which catches a thin slice of real defects. Everything else — memory corruption that doesn't crash, logic errors, spec violations — is invisible unless you supply an oracle. So the senior framing is: choosing and strengthening the oracle is usually higher-leverage than tuning the fuzzer, because it determines what classes of bug the campaign can even detect.

Q: Enumerate the oracle types, strongest to weakest.¶

Testing: Breadth — do you know there's a hierarchy beyond "it crashed"?

A. 1. Sanitizers (ASan/UBSan/MSan/TSan) — the workhorse. Catch memory-safety and UB the instant they occur, with stack traces and dedup. Convert "silent corruption" into "loud abort." Strongest general-purpose oracle for native code. 2. Assertions / contracts — assert(invariant) inside the code. Cheap, precise, and they encode your notion of correctness, not just memory safety. A fuzzer is an assertion-violation finding machine. (See 06 — Runtime Assertions & Contracts.) 3. Differential oracles — run two implementations on the same input and assert equal outputs (your parser vs a reference; old version vs new). Finds logic divergence that no sanitizer can see. 4. Round-trip / metamorphic oracles — assert decode(encode(x)) == x, parse(serialize(x)) == x, decompress(compress(x)) == x. Encodes an invariant without needing a reference implementation. 5. Crash-only (no extra oracle) — the default. Detects SIGSEGV/SIGABRT/timeout only. Weakest, but free.

The art is layering: ASan + assertions + a round-trip check in one harness multiplies what a single run can catch.

Q: Why specifically do ASan, UBSan, and MSan matter for a fuzzer?¶

Testing: Whether you can connect each sanitizer to a bug class the fuzzer would otherwise miss.

A. Because each turns a non-crashing defect into a detectable one, and fuzzers are exceptionally good at producing exactly those: - ASan — heap/stack/global buffer overflows, use-after-free, double-free. A 1-byte overflow usually doesn't crash; ASan's redzones catch it. This is the most valuable pairing in practice. - UBSan — signed integer overflow, shift-out-of-bounds, null-pointer deref, misaligned access, enum out of range. These are the bugs that "work fine" until the compiler optimizes on the assumption they never happen. - MSan — reads of uninitialized memory. Notoriously hard to find any other way because the value is often plausible garbage; MSan tracks each bit's initialized state.

Without these oracles the fuzzer reaches the buggy line and shrugs. With them, reaching the line is finding the bug.

Q: Why can't you combine ASan and MSan in one build, and what do you do about it?¶

Testing: A concrete, real constraint that trips people up.

A. They use incompatible, overlapping shadow-memory schemes and conflicting instrumentation, so you cannot link -fsanitize=address,memory into a single binary — the runtimes collide. (TSan likewise can't combine with ASan/MSan.) The practical consequence: you run separate fuzzing campaigns with different sanitizer builds. A typical fleet builds three targets from the same harness — an ASan build, a UBSan build (UBSan can ride along with ASan), and an MSan build — and fuzzes each, sharing one corpus between them. OSS-Gen/OSS-Fuzz does exactly this. So "which sanitizer" isn't either/or; it's "schedule all of them as parallel jobs over a shared corpus."

Q: A teammate says "we don't need sanitizers, the fuzzer will find crashes." Respond.¶

Testing: Whether you'll push back with the silent-corruption argument.

A. Crashes are the tip of the iceberg. The dangerous memory-safety bugs — the ones that become CVEs — frequently don't crash at the point of the bug: a heap overflow writes a few bytes past a buffer into adjacent valid heap, corrupting state that blows up much later (or never, locally) but is remotely exploitable. A fuzzer with no sanitizer runs straight past it because the process didn't die. The sanitizer is what makes the bug observable at its origin. So "the fuzzer finds crashes" is true and beside the point — we're not fuzzing to find the crashes we'd find anyway; we're fuzzing to find the silent corruption we otherwise never would. Dropping the sanitizer throws away most of the value of the campaign.

Practice at Scale¶

Q: What makes a good seed corpus, and why bother — won't the fuzzer figure it out?¶

Testing: Whether you understand seeds save the fuzzer from rediscovering the format.

A. Seeds are the difference between a fuzzer that's productive in an hour and one that spends days reinventing "this is a valid PNG." A good seed corpus is small, valid, and diverse: real examples that collectively exercise different features (a grayscale PNG, an indexed PNG, an interlaced one), each as small as possible. The fuzzer mutates from these, so it starts past the format-validation cliffs and spends its budget on the logic that actually has bugs. Skipping seeds means the fuzzer must blunder into a valid header by chance before it does anything useful — possible for trivial formats, hopeless for structured ones. Seed quality is one of the highest-leverage, lowest-effort inputs to a campaign.

Q: What is corpus minimization and why run it?¶

Testing: Operational hygiene — corpora rot without it.

A. A corpus grows monotonically and accumulates redundancy: hundreds of inputs that all hit the same edges, plus bloated inputs where only a few bytes matter. Minimization prunes this two ways: - Corpus-level merge (libFuzzer -merge=1, afl-cmin) — keep the smallest set of inputs that preserves total coverage. Drops redundant entries. - Per-input minimization (afl-tmin, libFuzzer's -minimize_crash) — shrink each input to the smallest form that still triggers the same coverage/crash.

You run it because a bloated corpus slows every future exec (bigger inputs, more to mutate) and because a minimized crash reproducer is what you hand to the person fixing the bug. Minimize the corpus periodically; always minimize a crash before filing it.

Q: What's a dictionary and when does it move the needle?¶

Testing: A cheap, high-ROI lever many people forget.

A. A dictionary is a list of meaningful tokens — keywords, magic constants, structural delimiters ("<html>", "GIF89a", "SELECT", 0x89504E47) — that the fuzzer inserts wholesale during mutation instead of discovering byte by byte. It moves the needle most for text/keyword-driven formats (SQL, JS, config languages) where the interesting branches gate on specific tokens. With CmpLog/trace-cmp doing some of this automatically, dictionaries matter less than they used to, but for grammar-heavy targets a good dictionary still measurably accelerates coverage. It's minutes of effort for a real speedup — cheap insurance.

Q: How should fuzzing fit into CI — per-PR, scheduled, or continuous?¶

Testing: Whether you know fuzzing is open-ended and can't just be "a test that passes."

A. All three, in layers, because fuzzing has no natural stopping point: - Per-PR smoke fuzzing — run each target for a short, bounded budget (e.g. 60 seconds) against the saved corpus. This is a regression gate: it re-runs the existing corpus (instant) plus a little new exploration, catching anything a change obviously breaks. Must be fast and deterministic enough not to flake the pipeline. - Scheduled deep fuzzing — nightly/weekly runs of hours per target, growing the corpus, on dedicated runners. - Continuous fuzzing — OSS-Fuzz / ClusterFuzz (or an internal equivalent) running targets 24/7 across many cores and sanitizer configs, with automatic crash dedup, bisection, and "verified fixed" tracking.

The mistake is treating fuzzing as a pass/fail unit test. It's a continuous search; CI's job is to gate regressions cheaply per-PR and let the deep search run out-of-band.

Q: A continuous fuzzer files a crash. Walk me through dedup, bisect, and verify-fixed.¶

Testing: The operational lifecycle, not just the find.

A. 1. Dedup — the same root-cause bug surfaces from thousands of distinct inputs. The infra hashes crashes by a normalized signature (top N sanitizer stack frames) so they collapse into one ticket, not ten thousand. 2. Minimize — shrink the reproducer to the smallest input that still triggers it (-minimize_crash), so the engineer debugs 12 bytes, not 2 MB. 3. Bisect — run the reproducer against the commit history to find the commit that introduced it (and confirm which builds it affects). ClusterFuzz automates this; it turns "somewhere in the last month" into a named commit and author. 4. Verify-fixed — after a fix lands, the infra re-runs the stored reproducer; only when it no longer triggers is the bug auto-closed. This prevents "we think we fixed it" and catches regressions if the bug comes back.

The reproducer is the through-line of the whole lifecycle — which is why minimization and saving it are non-negotiable.

Q: Which metrics tell you a fuzzing campaign is healthy?¶

Testing: Whether you measure the right things or just stare at "bugs found."

A. Three primary signals: - Executions per second (exec/s) — raw throughput. A drop (from 50k to 500) usually means the harness got slow (I/O, allocation, a logging call) and is the first thing to check; throughput is the budget everything else spends. - Coverage over time — edges/features reached. A rising curve means progress; a flat plateau means the fuzzer is stuck behind a barrier and needs intervention. - Time-to-bug / bugs-per-cpu-hour — the actual output, trending down as the code hardens.

The diagnostic combination: high exec/s but flat coverage = stuck behind a magic value or checksum; low exec/s = harness performance problem; coverage climbing, no bugs = either genuinely clean code or a missing oracle. You read them together.

Q: Coverage has plateaued. What are your remedies?¶

Testing: A practical toolbox, ordered.

A. In rough order of effort: 1. Add a dictionary — if it's stuck on keyword/magic-byte branches. 2. Enable CmpLog / trace-cmp — to get past comparisons against constants automatically. 3. Improve seeds — add real inputs that exercise the unreached features directly. 4. Patch out a blocker — a checksum or magic-byte gate; #ifdef FUZZING it and revalidate crashes unpatched. 5. Go structure-aware — if it's a grammar/protocol the byte-mutator can't keep valid. 6. Split the harness — one giant harness behind a mode switch starves sub-features; write focused harnesses per entry point. 7. More cores / longer time — last resort; throwing compute at a structural barrier rarely helps.

The plateau tells you where the fuzzer is blocked; the remedy depends on whether the wall is a value (dictionary/CmpLog), a structure (structure-aware), or a gate (patch it).

Limits¶

Q: "We hit 95% line coverage fuzzing, so the code is basically correct." What's wrong with that?¶

Testing: The coverage ≠ correctness distinction — the most important limit.

A. Coverage measures reach, not correctness. Executing a line tells you the line ran without crashing; it says nothing about whether the line produced the right answer. A function can be 100%-covered and wrong on every input if the oracle never checks the output. So high coverage with a crash-only oracle proves one thing: "we didn't find a crash on the paths we reached." It does not prove the logic is correct, that unreached paths are safe, or that the states (not just edges) you didn't reach are fine. Coverage is a necessary condition for finding a bug on a line (you can't find a bug on code you never run) but nowhere near sufficient. The correctness gap is exactly what differential and round-trip oracles exist to close.

Q: What kinds of bugs does coverage-guided fuzzing struggle to find?¶

Testing: Honest awareness of the technique's blind spots.

A. Several classes: - Deep stateful bugs — defects that require a specific sequence of operations to set up state (open → write → seek → close in a particular order). Single-input fuzzing struggles; you need stateful/sequence fuzzing that generates operation sequences, not just byte buffers. - Logic bugs with no oracle — a wrong financial calculation crashes nothing and violates no memory rule. Invisible without a differential or property oracle. - Bugs behind hard gates — strong checksums, decryption, signature checks that the fuzzer can't satisfy and you didn't patch out. - Concurrency bugs — timing-dependent races need TSan and often scheduling pressure the fuzzer doesn't naturally create. - Resource/algorithmic-complexity bugs — quadratic blowups show up as timeouts, not crashes, and need explicit detection.

Naming these is a green flag: it shows you don't think fuzzing is a silver bullet.

Q: How does property-based testing relate to fuzzing, and when do you reach for it instead?¶

Testing: Whether you see the family resemblance and the trade-off.

A. They're cousins. Property-based testing (QuickCheck, Hypothesis, Go's testing/quick) generates typed, often random-not-coverage-guided inputs and checks them against properties (invariants you assert). It's the lighter cousin: easier to write, runs in your normal test suite, and ships with a strong oracle baked in (the property) plus automatic shrinking. Coverage-guided fuzzing is heavier — instrumentation, a corpus, long runs — but explores far deeper because the coverage feedback directs the search.

Reach for property-based testing for pure functions and library logic where you can state an invariant and example-based tests can't cover the input space — it's a unit-test-grade tool. Reach for coverage-guided fuzzing for parsers, decoders, and any code crossing an untrusted boundary, where you need to discover the deep malformed inputs. They overlap: Go's f.Fuzz is literally coverage-guided property testing. See property-based testing in the testing section.

Q: You said "coverage without an oracle finds nothing." Where does that leave bugs no oracle can catch?¶

Testing: The oracle problem, and the bridge to formal methods.

A. This is the oracle problem: for some properties we genuinely don't have a cheap runtime check. Differential testing needs a reference implementation; round-trip needs an invertible operation; assertions need you to have thought of the invariant. When the property is subtle — "this concurrent data structure is linearizable," "this protocol never deadlocks," "this function is correct for all inputs, including the ones we'll never generate" — dynamic testing can only ever sample. Fuzzing finds bugs by example; it can show a bug exists but never that one is absent. That's the boundary where you graduate to formal methods: model checking and proof systems reason over all states symbolically, providing the "for all inputs" guarantee that no amount of fuzzing can. The two are complementary — fuzz to find bugs cheaply and continuously; verify formally where the cost of being wrong justifies a proof. See Formal Methods & Verification.

Scenario & Debugging¶

Q: "We fuzzed for a week and found nothing." List the likely causes.¶

Testing: Structured triage — the signature scenario of the whole topic.

A. "Found nothing" almost always means the setup is broken, not that the code is clean. Triage in order: 1. No oracle. Crash-only with no sanitizer? Then you only proved it doesn't segfault. Add ASan/UBSan — this is the most common cause by far. 2. Coverage isn't growing. Check the coverage curve. Flat from the start usually means the harness isn't actually reaching the target, or it's stuck behind a magic value/checksum at the entrance. 3. The harness fuzzes nothing. It validates input and returns early, or only ever calls one trivial path. Inspect what code the corpus actually covers (llvm-cov). 4. Throughput is in the floor. 50 exec/s instead of 50k — a week buys almost no iterations. Look for I/O, allocation, logging, or fork overhead in the hot loop. 5. Bad/empty seeds for a structured format, so the fuzzer never got past parsing. 6. The corpus wasn't persisted between runs, so every run restarted from zero.

The reframe: a week of "nothing" is diagnostic data. A correctly-wired fuzzer on a non-trivial parser finds something fast — so "nothing" points at the harness, the oracle, or the throughput, not at flawless code.

Q: A fuzzer is stuck at low coverage behind a checksum gate. How do you unblock it?¶

Testing: The concrete checksum problem and its real fixes.

A. First confirm it: coverage is flat and llvm-cov shows everything past the if (crc == stored) line is cold. CmpLog won't save you here — the expected CRC changes with every mutation, so the fuzzer can't learn a stable constant. Fixes, best first: 1. Patch out the check in a fuzz-only build. Wrap it: #ifndef FUZZING ... verify_crc() ... #endif. The fuzzer now flows past the gate and exercises the real logic. Re-run every crash against the unpatched binary to discard any that are only reachable with a bogus checksum. 2. Custom mutator that fixes the checksum. Have the mutator recompute and rewrite the CRC after mutating the payload, so every generated input is well-formed. More work, but no patched binary and no false positives. 3. Seed past it if only a few valid-checksum inputs are needed and the interesting logic is shallow beyond the gate (weakest — doesn't generalize).

Option 1 is the standard move; the discipline that makes it safe is re-validating crashes against the real build.

Q: A fuzzer found a crash. How do you turn it into a permanent regression test?¶

Testing: Finding a bug vs keeping it found — closing the loop.

A. The crash is worthless as a one-off; the value is a test that stays green after the fix. 1. Save and minimize the reproducer — -minimize_crash down to the smallest input that still triggers it. You get a small file, e.g. crash-7f3a.... 2. Add it to the corpus / a testdata directory. Both libFuzzer and Go re-run every file in the corpus on each invocation, so the reproducer becomes a permanent seed corpus entry that the per-PR smoke run replays — instant regression coverage. 3. In Go, this is first-class: the failing input is auto-written to testdata/fuzz/FuzzX/<hash> and committed; go test (no -fuzz) replays it forever as a normal unit test. No special infra needed. 4. Assert it under the same oracle that caught it (ASan build, or the assertion), so the regression test fails the same way if the bug returns. 5. Verify-fixed: confirm the reproducer crashes before the fix and passes after. That's the proof the fix is real, and the committed reproducer is what guards against regression.

The principle: a fuzz crash isn't done when it's fixed — it's done when the minimized reproducer is committed as a permanent, oracle-backed regression test.

Q: Your in-process libFuzzer target crashes on the second run with input that's fine in isolation. What's going on?¶

Testing: The in-process global-state trap.

A. Global state leaking across iterations. In-process fuzzing reuses one process for millions of inputs, so anything not reset between runs — a static cache, a global allocator pool, a singleton initialized once, an open file handle — accumulates. Iteration 1 leaves the world dirty; iteration 2 sees corrupted state and crashes on input that's perfectly valid on a clean start. Confirm by running the suspect input alone (./fuzzer crash-file) — if it passes in isolation but fails in sequence, it's state contamination, not a real input bug. Fixes: make the harness stateless/reentrant (reset or avoid the global), or run under a fork-server / persistent mode that gives each input a clean process. This is precisely the isolation the fork-server model buys you.

Rapid-Fire¶

Short questions to check breadth. One or two sentences each.

• Q: Coverage-guided in one line? A: Keep inputs that reach new edges, mutate from them, repeat — the program's structure directs the search.
• Q: Fuzzer = ? Sanitizer = ? A: Fuzzer = input generator; sanitizer = oracle. Generator finds the state, oracle notices it's bad.
• Q: What's the harness? A: The function you write that maps fuzzer bytes to a call into the code under test.
• Q: libFuzzer entry point? A: int LLVMFuzzerTestOneInput(const uint8_t *data, size_t size), returning 0.
• Q: Go fuzzing entry? A: f.Fuzz(func(t *testing.T, b []byte){...}), seeded with f.Add.
• Q: One flag to build a libFuzzer+ASan target? A: -fsanitize=fuzzer,address.
• Q: Why edge coverage over line coverage? A: It distinguishes which way a branch went, which is what reveals the untaken path.
• Q: What are counter buckets for? A: To treat "ran a loop 5 times vs 500 times" as different coverage without a counter explosion.
• Q: What beats magic bytes? A: Comparison instrumentation (CmpLog / trace-cmp) — the fuzzer sees the constant and inserts it.
• Q: Why are checksums harder than magic bytes? A: The expected value changes per input, so there's no stable constant to learn — patch it out or fix it in a custom mutator.
• Q: Can you combine ASan and MSan? A: No — incompatible shadow memory; run separate campaigns over a shared corpus.
• Q: Strongest free oracle vs strongest general oracle? A: Free = crash-only; general = a sanitizer.
• Q: Differential oracle? A: Two implementations, same input, assert equal outputs — finds logic divergence.
• Q: Round-trip oracle example? A: assert(decode(encode(x)) == x).
• Q: In-process vs fork-server trade-off? A: Speed vs isolation.
• Q: Corpus minimization, why? A: Drop redundant inputs to keep exec/s high; minimize crashes so reproducers are tiny.
• Q: What's a dictionary good for? A: Keyword/magic-token formats — inserts whole tokens instead of guessing them byte by byte.
• Q: Three health metrics? A: exec/s, coverage-over-time, time-to-bug.
• Q: High exec/s but flat coverage means? A: Stuck behind a magic value or checksum.
• Q: Coverage ≠ ? A: Correctness — reaching a line isn't checking it's right.
• Q: Property-based testing vs fuzzing? A: The lighter cousin — typed inputs + a built-in property oracle, runs in the normal test suite.
• Q: OSS-Fuzz in one line? A: Google's continuous fuzzing service — 24/7 runs, multi-sanitizer, auto dedup/bisect/verify-fixed.
• Q: Where fuzzing stops and formal methods start? A: Fuzzing samples and finds bugs by example; formal methods prove "for all inputs."

Red Flags / Green Flags¶

What interviewers infer from how you answer, not just whether you're right.

Red flags: - Describing fuzzing as "throwing random bytes" with no mention of coverage feedback. - No concept of an oracle — assuming "the fuzzer finds bugs" with nothing watching for them. - "The fuzzer found crashes, so we don't need sanitizers" — missing silent corruption entirely. - Treating coverage as a correctness metric ("95% covered = correct"). - Not knowing the harness is something you write, or that a bad harness fuzzes nothing. - Blaming "clean code" when a week of fuzzing finds nothing, instead of suspecting the setup. - Thinking you can just -fsanitize=address,memory in one build. - No idea how to turn a crash into a regression test — finding the bug but not keeping it found.

Green flags: - Naming the generator-vs-oracle split unprompted, and saying "coverage without an oracle finds nothing." - Reaching for ASan/UBSan as the oracle by reflex, and knowing to run MSan as a separate campaign. - Diagnosing "found nothing" structurally — oracle, coverage curve, harness, throughput — not vaguely. - Knowing the magic-bytes vs checksum distinction and that CmpLog handles one but not the other. - Measuring exec/s and coverage-over-time, and reading them together to localize a problem. - Committing a minimized reproducer as a permanent regression test, and re-validating patched-out crashes against the real build. - Caveating honestly — "fuzzing finds bugs by example, never proves their absence; that's where formal methods come in." - Treating fuzzing as a continuous search layered into CI (smoke per-PR, deep scheduled, continuous out-of-band), not a pass/fail unit test.

Cheat Sheet¶

Summary¶

• The bank reduces to four distinctions in costumes: generator vs oracle, coverage vs correctness, shallow vs deep/stateful bugs, finding a bug vs keeping it found. Name the distinction first; the flag follows.
• Coverage-guided means the fuzzer keeps inputs that reach new edges and breeds from them, turning a blind search into one directed by the program's structure — edge instrumentation, counter buckets, keep-on-new-edge, mutate.
• The oracle is the differentiator. Coverage without an oracle finds nothing; the fuzzer reaches the buggy state and a sanitizer (ASan/UBSan/MSan) is what notices it. ASan and MSan can't share a build — run them as separate campaigns over one corpus.
• Mechanism gotchas: CmpLog beats magic bytes by feeding the fuzzer the constants; checksums need patching-out or a custom mutator; deeply structured inputs need structure-aware fuzzing; in-process trades speed for fragility to global state.
• At scale it's a continuous search: good seeds, periodic corpus minimization, dictionaries for keyword formats, per-PR smoke + scheduled deep + continuous (OSS-Fuzz/ClusterFuzz), and a crash lifecycle of dedup → minimize → bisect → verify-fixed. Watch exec/s and the coverage curve together.
• Limits: coverage isn't correctness; logic, deep-stateful, and concurrency bugs slip past; property-based testing is the lighter cousin; the oracle problem is the bridge to formal methods, which prove what fuzzing can only sample.

Further Reading¶

• LLVM libFuzzer documentation — the in-process coverage-guided engine, harness contract, and flags referenced throughout.
• AFL++ documentation — fork-server, persistent mode, CmpLog, and custom mutators.
• Go Fuzzing — native coverage-guided fuzzing, f.Fuzz, and the testdata reproducer workflow.
• OSS-Fuzz and ClusterFuzz — continuous fuzzing at scale: dedup, bisection, multi-sanitizer, verify-fixed.
• The junior.md and senior.md pages of this topic — every answer here is grounded in those.
• man clang (-fsanitize=fuzzer, -fsanitize-coverage) — primary source for the instrumentation the answers reference.

Related Topics¶

• 01 — AddressSanitizer — the most valuable fuzzing oracle for native code; redzones turn silent overflows into loud aborts.
• 03 — UndefinedBehaviorSanitizer — the oracle for integer/shift/null UB; rides along with ASan in the same build.
• 06 — Runtime Assertions & Contracts — assertions as a cheap, precise oracle a fuzzer is exceptionally good at violating.
• Testing — where fuzzing sits in the test family, alongside its lighter cousin property-based testing.
• Formal Methods & Verification — the "for all inputs" guarantee that begins where dynamic sampling ends.