libfuzzer-sys

libfuzzer-sys is a barebones Rust wrapper around LLVM’s libFuzzer runtime, vendoring the libFuzzer C++ sources directly and building them via a build.rs script using the cc crate. Its main export is the fuzz_target! macro, which lets you define a fuzz entry point that libFuzzer’s coverage-guided engine repeatedly calls with generated inputs.

It is the engine underneath cargo fuzz, the recommended tool for fuzzing Rust code, and can also be used manually by wiring a binary crate’s main.rs to a fuzz_target! call and building with sanitizer-coverage flags. Because libFuzzer relies on LLVM sanitizer instrumentation, the crate currently only works on Linux (and other platforms with equivalent LLVM sanitizer support).

What You Get

• The fuzz_target! macro for declaring a fuzz entry point that closes over your own crate’s code
• Vendored libFuzzer C++ runtime sources, compiled and linked automatically via build.rs and the cc crate
• A Corpus enum for signaling whether a given input should be kept in or rejected from the fuzzing corpus
• Optional arbitrary/arbitrary-derive integration for generating structured fuzz inputs instead of raw bytes
• Support for linking a custom/prebuilt libFuzzer runtime via CUSTOM_LIBFUZZER_PATH for advanced setups

Common Use Cases

• Powering cargo fuzz targets to coverage-fuzz parsers, codecs, and other input-handling Rust code
• Fuzzing security-sensitive code paths (deserializers, protocol parsers) as part of a CI fuzzing pipeline
• Structured fuzzing of typed inputs via the arbitrary crate integration instead of raw byte slices
• Regression testing by replaying libFuzzer-discovered crash inputs as unit test cases

Under The Hood

Architecture - The crate has two halves: the vendored libfuzzer/ directory containing libFuzzer’s C++ sources (extracted from LLVM’s compiler-rt via git filter-branch and refreshed through update-libfuzzer.sh), and the Rust surface in src/lib.rs, which exposes the fuzz_target! macro and a Corpus enum for signaling keep/reject decisions. build.rs compiles the vendored C++ sources with the cc crate and links them into the final binary, or links a user-supplied prebuilt libFuzzer via the CUSTOM_LIBFUZZER_PATH environment variable — keeping the C++ toolchain concern isolated from the Rust API.

Tech Stack - Primarily C++ by byte count (the vendored libFuzzer runtime) with a thin Rust (edition = 2018) surface, built via build.rs + the cc crate rather than CMake (explicitly excluded from the crate package). Depends on arbitrary for structured input generation and dual-licenses under MIT OR Apache-2.0 for the Rust code, with the vendored libFuzzer directory under NCSA license as reflected in Cargo.toml’s composite license field.

Code Quality - The crate enforces #![deny(missing_docs, missing_debug_implementations)] at the crate root, meaning every public item must be documented and implement Debug — a stricter-than-default bar for a systems-level crate. Five example fuzz-target workspace members (example, example_arbitrary, example_crossover, example_init, example_mutator) double as both documentation and integration tests exercising different macro forms. A CHANGELOG.md is maintained per release.

API Design - The fuzz_target!(|data: &[u8]| { ... }) macro reduces the ceremony of wiring up libFuzzer’s C entry point to a single closure, and the crate is the de facto dependency cargo fuzz generates for new fuzz targets, so most users never interact with it directly beyond the macro. The main friction point is platform restriction to Linux (due to LLVM sanitizer support) and the need for a nightly-ish toolchain with sanitizer coverage flags for manual (non-cargo-fuzz) usage.