Security Research 101, Part 12: Reset State Between Fuzz Inputs

Fuzzing is often described as testing one input at a time, but in-process engines can call the target repeatedly inside the same process. That makes the harness part of the experiment: leftover caches, global counters, open files, or background threads can make one case affect the next. For a library you own or are explicitly authorized to test, keep the target narrow and make each iteration predictable: - Create per-input state and release it before returning. - Join worker threads and close or reset resources. - Avoid time- or randomness-driven behavior that does not come from the input. - Repeat a saved test case in a fresh run and after other corpus entries. If a crash appears only after a particular sequence, or coverage changes between identical inputs, investigate the harness and its reset logic before concluding the parser itself is inconsistent. Don’t “fix” instability by deleting inputs or suppressing crashes; retain the original reproducer and compare controlled runs. Some software is intentionally stateful, in which case the harness must model a valid sequence and reset only at the proper boundary. LLVM documents repeated in-process calls, deterministic behavior, speed, and global-state guidance for libFuzzer. AFL++’s persistent-mode guide explains that incomplete reset can cause false positives or waste fuzzing effort. Keep tests within your own local lab or explicit authorization. A fuzzer report is a lead, not proof of security impact. Sources: [LLVM libFuzzer: Fuzz Target](https://llvm.org/docs/LibFuzzer.html#fuzz-target) · [AFL++ persistent mode](https://github.com/AFLplusplus/AFLplusplus/blob/stable/instrumentation/README.persistent_mode.md) ~Cybersecurity