Fuzzing Rust Expert

Fuzzing Rust expert

This skill provides the agent with the knowledge and tools to write, build, and

validate fuzz targets for Rust projects integrated into OSS-Fuzz. Rust fuzzing

uses cargo-fuzz with the libfuzzer_sys crate, which drives libFuzzer.

Fundamental Concepts

OSS-Fuzz base image

Rust projects must use the Rust base builder image:

FROM gcr.io/oss-fuzz-base/base-builder-rust

Set language: rust in project.yaml.

Harness structure

Rust fuzz targets live in fuzz/fuzz_targets/<name>.rs within the crate being

fuzzed. The minimal harness using raw bytes:

#![no_main]
use libfuzzer_sys::fuzz_target;

fuzz_target!(|data: &[u8]| {
    // Call into the target. The fuzzer will mutate `data` on every iteration.
    let _ = my_crate::parse(data);
});

For structured fuzzing using the arbitrary crate (preferred when the target

expects typed input):

#![no_main]
use libfuzzer_sys::fuzz_target;
use arbitrary::Arbitrary;

#[derive(Debug, Arbitrary)]
struct MyInput {
    header: u8,
    payload: Vec<u8>,
    flags: u32,
}

fuzz_target!(|input: MyInput| {
    let _ = my_crate::process(input.header, &input.payload, input.flags);
});

The Cargo.toml for the fuzz directory must declare dependencies:

# fuzz/Cargo.toml
[package]
name = "my-crate-fuzz"
version = "0.0.0"
edition = "2021"
publish = false

[dependencies]
libfuzzer-sys = "0.4"
arbitrary = { version = "1", features = ["derive"] }   # only if using structured fuzzing

[dependencies.my-crate]
path = ".."

[[bin]]
name = "fuzz_target_name"
path = "fuzz_targets/fuzz_target_name.rs"
test = false
doc = false

Building in OSS-Fuzz

build.sh uses cargo fuzz build and then copies binaries to $OUT:

# build.sh
cd $SRC/<crate-dir>
cargo fuzz build -O   # -O enables release optimisations; important for performance

FUZZ_TARGET_OUTPUT_DIR=$SRC/<crate-dir>/target/x86_64-unknown-linux-gnu/release
for f in fuzz/fuzz_targets/*.rs; do
    name=$(basename "${f%.*}")
    cp "$FUZZ_TARGET_OUTPUT_DIR/$name" "$OUT/"
done

If the project requires a nightly toolchain, set it in the Dockerfile:

ENV RUSTUP_TOOLCHAIN=nightly

Or pin to a specific nightly for reproducibility:

ENV RUSTUP_TOOLCHAIN=nightly-2025-07-03

Seed corpus and dictionaries

• Place seed files in fuzz/corpus/<target_name>/ within the repo; they are

automatically picked up by cargo-fuzz and can be zipped for OSS-Fuzz.

• To ship a corpus with OSS-Fuzz copy a zip to $OUT/<target_name>_seed_corpus.zip.
• Dictionaries go to $OUT/<target_name>.dict.
• For targets that parse a structured format, generating seeds with a script

beats hand-picking a few files — random mutation rarely passes the parser's

early checks (note: cargo-fuzz's arbitrary is the better route when the

target takes typed data rather than a byte format). See the [structured seed

generation reference](../oss-fuzz-engineer/references/structured_seed_generation.md).

Characteristics of good Rust fuzzing harnesses

• Targets attack surface: parsers, deserializers, protocol implementations,

unsafe blocks, and any API that processes untrusted bytes.

• Uses structured fuzzing (arbitrary) when the target expects typed data

rather than raw bytes — this dramatically improves coverage.

• Handles expected errors: Result and Option should be let-bound and

ignored (let _ = ...). Only actual panics are findings.

• Avoids panicking on every input: do not use .unwrap() or .expect()

on fallible operations driven by fuzz input — these create false positives.

• Avoids non-determinism: no rand, no system time, no thread spawning

inside the fuzz callback.

• Is fast: avoid I/O, heavy allocations, or expensive setup inside the

callback; do those outside the fuzz_target! macro if needed with

LazyLock / OnceLock.

• Considers unsafe code: if the crate has unsafe blocks, write

harnesses that exercise those paths — this is where memory bugs can still

occur in Rust.

• Builds in release mode (-O): fuzzing in debug mode is much slower.

What Rust fuzzing finds

Rust's ownership model prevents most memory-corruption bugs, but fuzzing still

finds:

• Panics: unwrap/expect on None/Err, index out of bounds,

arithmetic overflow in debug mode, explicit panic! calls.

• unsafe bugs: use-after-free, out-of-bounds reads/writes, undefined

behaviour in unsafe blocks — these are real memory bugs.

• Logic errors: incorrect parsing, data corruption, wrong output.
• Hangs: infinite loops triggered by crafted input.
• Stack overflows: deep recursion on adversarial input.

Operational guidelines

• Always validate with:

  python3 infra/helper.py build_fuzzers <project>
  python3 infra/helper.py check_build <project>
  python3 infra/helper.py run_fuzzer <project> <fuzzer_name> -- -max_total_time=30

• An instant crash usually means a panic! on every input — check for

.unwrap() calls on fuzz-driven paths and replace with if let or ?.

• Run cargo build and cargo test inside the crate before adding the fuzz

harness to catch pre-existing compilation errors.

• When iterating locally clone the upstream repo and switch the Dockerfile from

RUN git clone to COPY to avoid network round-trips.

• If the crate uses no_std, use libfuzzer-sys's no_std feature and ensure

the harness does not rely on std.

• Document why each entry point was chosen and what class of bugs it may find.