rust-fuzz / cargo-fuzz Goto Github PK

View Code? Open in Web Editor NEW

1.5K 25.0 109.0 469 KB

Command line helpers for fuzzing

Home Page: https://rust-fuzz.github.io/book/cargo-fuzz.html

License: Apache License 2.0

Rust 100.00%

fuzz-testing fuzzing cargo rust

cargo-fuzz's Introduction

`cargo fuzz`

A cargo subcommand for fuzzing with libFuzzer! Easy to use!

Installation

$ cargo install cargo-fuzz

Note: libFuzzer needs LLVM sanitizer support, so this only works on x86-64 and Aarch64, and only on Unix-like operating systems (not Windows). You'll also need a C++ compiler with C++11 support.

Usage

`cargo fuzz init`

Initialize a cargo fuzz project for your crate!

If your crate uses cargo workspaces, add `fuzz` directory to `workspace.members` in root `Cargo.toml`

fuzz directory can be either a part of an existing workspace (default) or use an independent workspace. If latter is desired, you can use cargo fuzz init --fuzzing-workspace=true.

`cargo fuzz add <target>`

Create a new fuzzing target!

`cargo fuzz run <target>`

Run a fuzzing target and find bugs!

`cargo fuzz fmt <target> <input>`

Print the std::fmt::Debug output for a test case. Useful when your fuzz target takes an Arbitrary input!

`cargo fuzz tmin <target> <input>`

Found a failing input? Minify it to the smallest input that causes that failure for easier debugging!

`cargo fuzz cmin <target>`

Minify your corpus of input files!

`cargo fuzz coverage <target>`

Generate coverage information on the fuzzed program!

Documentation

Documentation can be found in the Rust Fuzz Book.

You can also always find the full command-line options that are available with --help:

$ cargo fuzz --help

Trophy case

The trophy case has a list of bugs found by cargo fuzz (and others). Did cargo fuzz and libFuzzer find a bug for you? Add it to the trophy case!

License

cargo-fuzz is distributed under the terms of both the MIT license and the Apache License (Version 2.0).

See LICENSE-APACHE and LICENSE-MIT for details.

cargo-fuzz's People

Contributors

Stargazers

Watchers

Forkers

nagisa vks mbrubeck blt sinkuu birkenfeld emk mcarton nygrenh ruuda killercup lifthrasiir dwrensha hoverbear alanhdu deweerdt danburkert bennofs orf53975 fauxfaux paulgrandperrin dgreid fuzzamos ekleog entropy1337 alexcrichton isgasho marshallpierce jeongjaegu pnordahl benesch kornelski phlip9 alex rhysd atul9 fitzgen lezzokafka thebluematt 5l1v3r1 c410-f3r spudmashmedia shnatsel ian-fox tmroeder zmilan jeanmanguy horki mrmaxmeier alpha-sierra-hotel-yankee-alpha concordium tilpner icodein paholg davidkorczynski evverx adomore darosior dr-r00t3r danielframpton voteblake name1e5s katuramu-nic lynnkirby saethlin greyspectrum newam de-husk valera-datasakura dtolnay-contrib katsuragicsl ahmedsakrr evanrichter kianmeng fpxtest oxy-archive patilraj2407 rossmacarthur woodscumming sumodgeorge silvergasp luni-4 sylvestre kveinaxel trail-of-forks jauvany f0rki ops-l voker57 manunio mgeisler kangjana cuan-bersama zhu1971 void0red 0xalpharush cjangming jonboh kdarkhan legendsaber

cargo-fuzz's Issues

One point oh

Is there anything blocking 1.0? My main reasons for not 1.0-ing this earlier was that the exact mechanics were in flux (building libfuzzer, the fuzz/ dir, etc), and the CLI was uncertain.

Now we have a proper CLI that probably won't change. We don't do a special libfuzzer build anymore. The fuzz scripts are much cleaner (macros!) and while we may add quickcheck support later, I don't think that will be backwards-incompatible.

Is there anything else we need to decide, or issues that should be fixed, before going 1.0?

cc @frewsxcv @nagisa

Should create corpus directory with the creation of fuzz directory

Add proper tests for CI

It should cd to a test crate directory, that contains a single function which panics on an input of size 6 or something, then fuzz init, edit the fuzz target to call this function, run the fuzz target, and ensure a crashfile is produced of the correct length.

Move to clap

@nagisa has mentioned this a few times

Use --target x86_64-unknown-linux-gnu to prevent being called on build scripts

https://www.reddit.com/r/rust/comments/5va0mi/cargofuzz_an_easy_way_to_fuzz_your_crates/de0pyt5/

We may still need it so that libfuzzer itself isn't instrumented.

--init in serde-json checkout panics

$ git clone 'https://github.com/serde-rs/json.git' && cd json
$ cargo fuzz --init
thread 'main' panicked at 'called `Option::unwrap()` on a `None` value', /checkout/src/libcore/option.rs:323
stack backtrace:
   1:     0x5623cfbb8d89 - std::sys::imp::backtrace::tracing::imp::write::hbb14611794d3841b
                        at /checkout/src/libstd/sys/unix/backtrace/tracing/gcc_s.rs:42
   2:     0x5623cfbbdf6e - std::panicking::default_hook::{{closure}}::h6ed906c7818ac88c
                        at /checkout/src/libstd/panicking.rs:351
   3:     0x5623cfbbdb74 - std::panicking::default_hook::h23eeafbf7c1c05c3
                        at /checkout/src/libstd/panicking.rs:367
   4:     0x5623cfbbe36b - std::panicking::rust_panic_with_hook::hd0067971b6d1240e
                        at /checkout/src/libstd/panicking.rs:545
   5:     0x5623cfbbe1f4 - std::panicking::begin_panic::h1fd1f10a3de8f902
                        at /checkout/src/libstd/panicking.rs:507
   6:     0x5623cfbbe169 - std::panicking::begin_panic_fmt::haa043917b5d6f21b
                        at /checkout/src/libstd/panicking.rs:491
   7:     0x5623cfbbe0f7 - rust_begin_unwind
                        at /checkout/src/libstd/panicking.rs:467
   8:     0x5623cfbe860d - core::panicking::panic_fmt::he9c7f335d160b59d
                        at /checkout/src/libcore/panicking.rs:69
   9:     0x5623cfbe8544 - core::panicking::panic::hb790668694ff6b20
                        at /checkout/src/libcore/panicking.rs:49
  10:     0x5623cf93bebc - <core::option::Option<T>>::unwrap::hbd802f172b858ee2
                        at /checkout/src/libcore/macros.rs:21
  11:     0x5623cf949cc8 - cargo_fuzz::init_fuzz::hca902791dd2a2f92
                        at /home/nagisa/Documents/rust/cargo-fuzz/src/main.rs:80
  12:     0x5623cf949334 - cargo_fuzz::main::hba96e14eae3eda3f
                        at /home/nagisa/Documents/rust/cargo-fuzz/src/main.rs:46
  13:     0x5623cfbc526a - __rust_maybe_catch_panic
                        at /checkout/src/libpanic_unwind/lib.rs:98
  14:     0x5623cfbbeb16 - std::rt::lang_start::hb7fc7ec87b663023
                        at /checkout/src/libstd/panicking.rs:429
                        at /checkout/src/libstd/panic.rs:361
                        at /checkout/src/libstd/rt.rs:57
  15:     0x5623cf94d502 - main
  16:     0x7ff37431d290 - __libc_start_main
  17:     0x5623cf93a949 - _start
  18:                0x0 - <unknown>

Shadow memory range interleaves with an existing memory mapping. ASan cannot proceed correctly. ABORTING

Hi,

cargo-fuzz is not working anymore here, but I cannot find the source of the problem. The error is triggered when starting the fuzzer:

$ cargo fuzz run fuzzer_script_1
...
     Running `fuzz/target/x86_64-unknown-linux-gnu/debug/fuzzer_script_1 -artifact_prefix=/home/pollux/CODE/RUST/der-parser/fuzz/artifacts/fuzzer_script_1/ /home/pollux/CODE/RUST/der-parser/fuzz/corpus/fuzzer_script_1`
==6747==Shadow memory range interleaves with an existing memory mapping. ASan cannot proceed correctly. ABORTING.
==6747==ASan shadow was supposed to be located in the [0x00007fff7000-0x10007fff7fff] range.
==6747==Process memory map follows:
	0x0005eba8d000-0x0005ebc94000	/home/pollux/CODE/RUST/der-parser/fuzz/target/x86_64-unknown-linux-gnu/debug/fuzzer_script_1
	0x0005ebe93000-0x0005ebe98000	/home/pollux/CODE/RUST/der-parser/fuzz/target/x86_64-unknown-linux-gnu/debug/fuzzer_script_1
	0x0005ebe98000-0x0005ebe9f000	/home/pollux/CODE/RUST/der-parser/fuzz/target/x86_64-unknown-linux-gnu/debug/fuzzer_script_1
	0x0005ebe9f000-0x0005edd2a000	
	0x0005edd2a000-0x0005f18ed000	
	0x0005f18ed000-0x0005f18ee000	[heap]
	0x03a358fd1000-0x03a359323000	
	0x03a359323000-0x03a359426000	/lib/x86_64-linux-gnu/libm-2.24.so
	0x03a359426000-0x03a359625000	/lib/x86_64-linux-gnu/libm-2.24.so
	0x03a359625000-0x03a359626000	/lib/x86_64-linux-gnu/libm-2.24.so
	0x03a359626000-0x03a359627000	/lib/x86_64-linux-gnu/libm-2.24.so
	0x03a359627000-0x03a3597bc000	/lib/x86_64-linux-gnu/libc-2.24.so
	0x03a3597bc000-0x03a3599bb000	/lib/x86_64-linux-gnu/libc-2.24.so
	0x03a3599bb000-0x03a3599bf000	/lib/x86_64-linux-gnu/libc-2.24.so
	0x03a3599bf000-0x03a3599c1000	/lib/x86_64-linux-gnu/libc-2.24.so
	0x03a3599c1000-0x03a3599c5000	
	0x03a3599c5000-0x03a3599db000	/lib/x86_64-linux-gnu/libgcc_s.so.1
	0x03a3599db000-0x03a359bda000	/lib/x86_64-linux-gnu/libgcc_s.so.1
	0x03a359bda000-0x03a359bdb000	/lib/x86_64-linux-gnu/libgcc_s.so.1
	0x03a359bdb000-0x03a359bdc000	/lib/x86_64-linux-gnu/libgcc_s.so.1
	0x03a359bdc000-0x03a359bf4000	/lib/x86_64-linux-gnu/libpthread-2.24.so
	0x03a359bf4000-0x03a359df3000	/lib/x86_64-linux-gnu/libpthread-2.24.so
	0x03a359df3000-0x03a359df4000	/lib/x86_64-linux-gnu/libpthread-2.24.so
	0x03a359df4000-0x03a359df5000	/lib/x86_64-linux-gnu/libpthread-2.24.so
	0x03a359df5000-0x03a359df9000	
	0x03a359df9000-0x03a359e00000	/lib/x86_64-linux-gnu/librt-2.24.so
	0x03a359e00000-0x03a359fff000	/lib/x86_64-linux-gnu/librt-2.24.so
	0x03a359fff000-0x03a35a000000	/lib/x86_64-linux-gnu/librt-2.24.so
	0x03a35a000000-0x03a35a001000	/lib/x86_64-linux-gnu/librt-2.24.so
	0x03a35a001000-0x03a35a003000	/lib/x86_64-linux-gnu/libdl-2.24.so
	0x03a35a003000-0x03a35a203000	/lib/x86_64-linux-gnu/libdl-2.24.so
	0x03a35a203000-0x03a35a204000	/lib/x86_64-linux-gnu/libdl-2.24.so
	0x03a35a204000-0x03a35a205000	/lib/x86_64-linux-gnu/libdl-2.24.so
	0x03a35a205000-0x03a35a377000	/usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.22
	0x03a35a377000-0x03a35a577000	/usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.22
	0x03a35a577000-0x03a35a581000	/usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.22
	0x03a35a581000-0x03a35a583000	/usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.22
	0x03a35a583000-0x03a35a587000	
	0x03a35a587000-0x03a35a5aa000	/lib/x86_64-linux-gnu/ld-2.24.so
	0x03a35a76c000-0x03a35a782000	
	0x03a35a790000-0x03a35a7a6000	
	0x03a35a7a6000-0x03a35a7a8000	[vvar]
	0x03a35a7a8000-0x03a35a7aa000	[vdso]
	0x03a35a7aa000-0x03a35a7ab000	/lib/x86_64-linux-gnu/ld-2.24.so
	0x03a35a7ab000-0x03a35a7ac000	/lib/x86_64-linux-gnu/ld-2.24.so
	0x03a35a7ac000-0x03a35a7ad000	
	0x03eca912c000-0x03eca914e000	[stack]
==6747==End of process memory map.

cargo-fuzz version 0.4.1
llvm & clang version 3.8.1 (Debian)
rustc 1.18.0-nightly
note: compiled kernel with grsecurity, I don't know if that is of any importance - cargo-fuzz 0.3.1 worked previously on the same kernel.

The same happens when creating a new crate (type lib) and adding a fuzzer.

How long it takes to finish fuzzing?

It's not directly related to the cargo-fuzz, more to the llvm.

I'm new to fuzz-testing and can't understand how long it takes to finish fuzzing. Is it endless? Is there a progress somewhere in the output?

Now I'm just shutting down it after ~10 minutes.

Trophy case

🏆 🏆

toml-rs panic

workspace member `Cargo.toml` is not hierarchically below the workspace root `fuzz/Cargo.toml`

Hi,

I wanted to checkout cargo fuzz but the cargo fuzz run fuzzer_script_1 fails on freshly created cargo workspace

cargo init test_fuzz
cd test_fuzz 
cargo fuzz init

Fails with:

error: workspace member '/path/to/test_fuzz/Cargo.toml' is not hierarchically below the workspace root '/path/to/test_fuzz/fuzz/Cargo.toml'

I am testing on the latest stable:
rustc 1.15.1 (021bd294c 2017-02-08)
cargo 0.16.0-nightly (6e0c18c 2017-01-27)

To duble check with some other example from github
https://github.com/Manishearth/unicode-segmentation.git (checked out the fuzz branch and corrected the [package.metadata] in fuzz/cargo.toml) and unfortunately the result was identical.

error: workspace member '/path/to/unicode-segmentation/Cargo.toml' is not hierarchically below the workspace root '/path/to/unicode-segmentation/fuzz/Cargo.toml'

Am I doing something wrong or are the instructions outdated?

What am I doing wrong?

First of all, the README says --fuzz-target , but it looks like it's --target now.

Secondly, with this script:

extern crate semver;

#![no_main]
extern crate fuzzer_sys;

use semver::Version;

#[export_name="LLVMFuzzerTestOneInput"]
pub extern fn go(data: &[u8]) {
    let _ = Version::parse("1.2.3");
}

I get this

error: an inner attribute is not permitted in this context
 --> fuzzers/fuzzer_script_1.rs:3:3
  |
3 | #![no_main]
  |   ^
  |
  = note: inner attributes and doc comments, like `#![no_std]` or `//! My crate`, annota
te the item enclosing them, and are usually found at the beginning of source files. Oute
r attributes and doc comments, like `#[test]` and
                                             `/// My function`, annotate the item follow
ing them.

error: main function not found

the no main stuff was generated by --init. I'm very confused.

Add trophies for capnp

https://dwrensha.github.io/capnproto-rust/2017/02/27/cargo-fuzz.html

e.g. capnproto/capnproto-rust@6f9bbdc

Feature request: allow fuzz function to signal error in harness

I have a fuzz function that translates 12 bytes to a CAN frame. 4 for the header and up to 8 for the payload. If the fuzzer gets passed less than 4 or more then 12 it will reject and return immediately. This still results in a case in the corpus.

It would be nice to be able to return a result that signals that the input is not valid at all and that it will not end up in the corpus. Maybe even something like:

enum FuzzerResult {
    InputToShort,
    InputToLong,
    ErrorInHarness,
}

Feature request: Setup and teardown functions

Maybe I missed something in the docs But I'd like to request the following feature:

Add a function that will be called once before the fuzzing starts to set up stuff needed for fuzzing. Maybe with a method to pass that data as an argument to the fuzz function.

Two reasons:

Expensive setup means the fuzzer runs slower. I would have used lazy_static but it does not play nice with the sanitizer
Some setup is to cumbersome to do every test. I am currently fuzzing a program that accepts CAN packets and I need to setup a virtual can network beforehand. This would also need a teardown function.

Better error handling

Add colors, use error_chain, etc.

Add some CI

Using multiple crate types leads to link errors

For fuzzing, I always have to make sure my crate type is set to rlib, or rlib and staticlib. Reversing the order or adding the bin crate type leads to link errors. Is this expected or specific to my setup? Happy to provide a sample if necessary.

Figure out a solution for the stdlib

Libstd isn't built with sanitizer support. Perhaps we should release a version that is.

Find executables more consistently and report better errors

For now when we cannot find the executable (which tends to move around due to all the changes and cargo being weird) we print just

Error: entity not found

which is extremely uninformative.

2 action points:

improve error messages (error-chain is great for that!)
search for executable in more locations; make cargo-fuzz search it from the fuzz root[1] and not just hope its there;

[1]: cargo root can be easily annotated with [package.metadata.fuzz] (cargo does not complain about non-existing toml key in [package.metadata]).

Add ability to pass extra options to libFuzzer

Being able to adjust some of the libFuzzer options (e.g max_len) would be useful, currently this seems to be only possible by editing the source of cargo-fuzz or using libFuzzer directly.

A simple solution would be to provide some pass-through argument to cargo fuzz that will passed to libFuzzer. (Similar to what rustc has with llvm options.)

Mention C++ compiler with C++11 support is needed

rust-fuzz/targets#14 (comment)

Support for MacOS via libfuzzer

There's supposedly support for libfuzzer on MacOS in the latest LLVM (I think?). Opening this here as a tracking issue and reminding us we might need to change what was added here.

Entity not found

Running cargo fuzz --fuzz-target fuzzer_script_1 results in a Error: Entity not found.

Discussed with @nagisa about this issue on IRC, the cause is

"since we started passing in the --target=xxx flag, it puts the executable in fuzz/target/<TARGET>/debug where cargo-fuzz looks for it in fuzz/target/debug"

Consider adding a full tutorial / book via mdbook

Similar to what afl.rs has:

https://rust-fuzz.github.io/afl.rs/

https://github.com/rust-fuzz/afl.rs/tree/master/docs/src

I'd be willing to write it if others think it'd be helpful.

It also might make sense to have a new repository: rust-fuzz/book

Add support for AFL

Would be nice if we could cargo fuzz --fuzzer afl on binary crates. Or something. Might need to set up the whole LLVM shebang.

cc @frewsxcv

How to disable memory leaks detection?

I'm getting:

SUMMARY: AddressSanitizer: 433 byte(s) leaked in 3 allocation(s).
INFO: a leak has been found in the initial corpus.
INFO: to ignore leaks on libFuzzer side use -detect_leaks=0.

I don't know is it are real leaks because it triggered by Rc::new().

PS: maybe this issue should be treated as "How to pass custom flags to libFuzzer", which is not done yet (AFAIK).

Feature request: Allow the writer to specify a pretty printer for artifacts

I noticed that I wanted to pretty print the artefacts. Especially because sometimes the raw artefact is a bit hard to read.

The code I need for that is very similar to the actual fuzzer. It would be nice to have a pretty print function for artefacts. It should be used standalone to show an artefact file. But it can also be used during runs to print a more meaningful message than a set of bytes

Cannot choose custom allocator

Anything using a custom allocator cannot be fuzzed, even if the same allocator is chosen in the fuzzer script.

add check artifact command

If the program panics an artifact is written. I then try to fix the bug causing the panic. Now I want to check if I really fixed the bug. A command like
cargo fuzz check my_fuzzer crash-2c66bb9f0dabeaf158f68a7eea3b5033080173c3 would be useful that invokes go(data) with this artifact again.

BTreeSet and HashSet cause AddressSanitizer errors

#[export_name="rust_fuzzer_test_input"]
pub extern "C" fn go(data: &[u8]) {
    let mut bt: BTreeSet<u64> = BTreeSet::new();
    bt.insert(0);
}

#[export_name="rust_fuzzer_test_input"]
pub extern "C" fn go(data: &[u8]) {
    let mut bt: HashSet<u64> = HashSet::new();
    bt.insert(0);
}

Both of these functions cause a AddressSanitizer error for me. Here is the one for BTreeSet:

INFO: Seed: 765651658
INFO: Loaded 0 modules (0 guards): 
Loading corpus dir: corpus
INFO: -max_len is not provided, using 64
#0	READ units: 20
=================================================================
==15413==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7fff8e0a6f10 at pc 0x55a091206598 bp 0x7fff8e0a60d0 sp 0x7fff8e0a60c8
ACCESS of size 0 at 0x7fff8e0a6f10 thread T0
    #0 0x55a091206597  (/home/brain/src/roaring-rs/fuzz/target/x86_64-unknown-linux-gnu/debug/fuzzer_script_1+0xf597)
    #1 0x55a0912374f9  (/home/brain/src/roaring-rs/fuzz/target/x86_64-unknown-linux-gnu/debug/fuzzer_script_1+0x404f9)
    #2 0x55a091229463  (/home/brain/src/roaring-rs/fuzz/target/x86_64-unknown-linux-gnu/debug/fuzzer_script_1+0x32463)
    #3 0x55a091229503  (/home/brain/src/roaring-rs/fuzz/target/x86_64-unknown-linux-gnu/debug/fuzzer_script_1+0x32503)
    #4 0x55a09123e945  (/home/brain/src/roaring-rs/fuzz/target/x86_64-unknown-linux-gnu/debug/fuzzer_script_1+0x47945)
    #5 0x55a09124256a  (/home/brain/src/roaring-rs/fuzz/target/x86_64-unknown-linux-gnu/debug/fuzzer_script_1+0x4b56a)
    #6 0x55a09124060f  (/home/brain/src/roaring-rs/fuzz/target/x86_64-unknown-linux-gnu/debug/fuzzer_script_1+0x4960f)
    #7 0x55a09137970b  (/home/brain/src/roaring-rs/fuzz/target/x86_64-unknown-linux-gnu/debug/fuzzer_script_1+0x18270b)

Address 0x7fff8e0a6f10 is located in stack of thread T0 at offset 48 in frame
    #0 0x55a091236f0f  (/home/brain/src/roaring-rs/fuzz/target/x86_64-unknown-linux-gnu/debug/fuzzer_script_1+0x3ff0f)

  This frame has 5 object(s):
    [32, 48) '_11' <== Memory access at offset 48 is inside this variable
    [64, 136) 'iter'
    [176, 200) '_6'
    [240, 312) '_5'
    [352, 424) '_4'
HINT: this may be a false positive if your program uses some custom stack unwind mechanism or swapcontext
      (longjmp and C++ exceptions *are* supported)
SUMMARY: AddressSanitizer: stack-buffer-overflow (/home/brain/src/roaring-rs/fuzz/target/x86_64-unknown-linux-gnu/debug/fuzzer_script_1+0xf597) 
Shadow bytes around the buggy address:
  0x100071c0cd90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x100071c0cda0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x100071c0cdb0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x100071c0cdc0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x100071c0cdd0: 00 00 00 00 00 00 00 00 00 00 00 00 f1 f1 f1 f1
=>0x100071c0cde0: 00 00[f2]f2 00 00 00 00 00 00 00 00 00 f2 f2 f2
  0x100071c0cdf0: f2 f2 00 00 00 f2 f2 f2 f2 f2 00 00 00 00 00 00
  0x100071c0ce00: 00 00 00 f2 f2 f2 f2 f2 00 00 00 00 00 00 00 00
  0x100071c0ce10: 00 f3 f3 f3 f3 f3 f3 f3 00 00 00 00 00 00 00 00
  0x100071c0ce20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x100071c0ce30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:       fa
  Heap right redzone:      fb
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack partial redzone:   f4
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
  Left alloca redzone:     ca
  Right alloca redzone:    cb
==15413==ABORTING
MS: 0 ; base unit: 0000000000000000000000000000000000000000


artifact_prefix='artifacts/'; Test unit written to artifacts/crash-da39a3ee5e6b4b0d3255bfef95601890afd80709
Base64:

Can other people reproduce this? I think this is because rust does not support AddressSanitizer. Can it be disabled for cargo-fuzz? There don't appear to be any flags to set to work around it.

cargo-fuzz --init does not work

$ cargo-fuzz --init
Invalid arguments.

Usage:
  cargo fuzz --init

Increasingly inclined to move from docopt to clap. I may get around to that eventually. Move to clap should also help with making a more flexible parser to pass various extra options to the executable and rustc.

Note that this is nightly only

Initialization fails in workspaced directories

If I have a directory like this:

my_first_binary
my_second_binary
Cargo.toml

Where Cargo.toml only contains something like this:

[workspace]
members = [
    "my_first_binary",
    "my_second_binary"
]

Then initialization fails on an unwrap of None on an Option (though it doesn't say which one). It would be nice if cargo-fuzz could worked with workspaced projects so that it has one folder with targets for all binaries in the workspace.

Consider `cargo fuzz <fuzz target>` instead of `cargo fuzz --fuzz-target <fuzz target>`

Considering cargo fuzz --fuzz-target <fuzz target> is the main command here and going to be called the most, it seems unfortunate it's a pretty long CLI call. Maybe we should migrate to cargo fuzz <fuzz target>? Thoughts?

Remove lockfile

See discussion here:

#43

Also add to gitignore

RUSTFLAGS are ignored

It seems like RUSTFLAGS are ignored when compiling the fuzzer script. This makes it impossible to fuzz crates that rely on e.g. AVX2.

Does not work on Windows Subsystem for Linux

This is a known issue:

I just figured it'd be a good idea to have some notice here to save other Windows users from having to find the answer themselves. (Maybe add a note to the README as well?)

This is the kind of error message you get:

==6089==Sanitizer CHECK failed: [...]/sanitizer_common/sanitizer_procmaps_linux.cc:57 ((IsOneOf(*current_, 's', 'p'))) != (0) (0, 0)

Not very helpful, but Googling Sanitizer CHECK failed IsOneOf turned up the above issues.

Add AppVeyor CI

I just opened a PR to fix the build on Windows. It would be great to setup AppVeyor to ensure future PRs are built correctly on Windows as well.

Should cargo-fuzz generate dummy fuzzer with macro util?

cargo-fuzz/src/main.rs

Lines 155 to 163 in 99c3647

 fn dummy_target(script: &mut fs::File, pkg: &Package) -> Result<(), Box<error::Error>> { 

 write!(script, r#"#![no_main] 

 extern crate libfuzzer_sys; 

 {} 

 #[export_name="rust_fuzzer_test_input"] 

 pub extern fn go(data: &[u8]) {{ 

  // fuzzed code goes here 

 }}"#, link_to_lib(pkg).unwrap_or(String::new())).map_err(|e| e.into()) 

 }

https://github.com/rust-fuzz/libfuzzer-sys/blob/d899978f3f4d594d1495a277ac184271e180b4be/src/lib.rs#L18-L32

README instructions are wrong

existing/broken: $ cargo fuzz --fuzz-target fuzzer_script_1

Fix: $ cargo fuzz --target fuzzer_script_1

opt-level = 3?

By adding the following to fuzz/Cargo.toml:

+[profile.dev]
+opt-level = 3

…I improve fuzzer throughput from:

#524288	pulse  cov: 3738 corp: 80/10238b exec/s: 1420 rss: 574Mb

...to:

#1048576	pulse  cov: 1584 corp: 79/10254b exec/s: 6808 rss: 594Mb

What would the tradeoffs be for including this in the default Cargo.toml, or at least documenting it?

Document the meaning of output

I tried this but I don't understand what the output means. It'd be helpful if it was documented.

lazy_static triggers AddressSanitizer errors

In BurntSushi/rust-snappy#5, it looks like the error is coming from Lazy::get().

This possibly has the same root cause as #81, but I don't know enough about how lazy_static works to be able to say for sure.

Allow specifying features (and maybe set a default feature)

In order to have some focused fuzzing, I'd like to be able to expose some private methods only when fuzzing. However, I don't see how to pass in Cargo feature flags:

$ cargo fuzz run expression --features=test --release
error: Found argument '--features' which wasn't expected, or isn't valid in this context

$ cargo fuzz run --features=test expression --release
error: Found argument '--features' which wasn't expected, or isn't valid in this context

$ cargo fuzz --features=test run expression --release
error: Found argument '--features' which wasn't expected, or isn't valid in this context

Even better, it might be nice if cargo fuzz implicitly set a feature the same way that cargo test does.

Run with detect_odr_violations=0

Probably should turn off most of the asan checks. I needed ASAN_OPTIONS=detect_odr_violation=0 to make it work on rust-url, otherwise it would bail very early.

More configurability

Add the ability to choose between debug/release. Pass down any other useful rustc flags.

Undefined reference to `rust_begin_unwind`

Ideas?

  = note: /home/steve/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libcore-cd0ca85e71f914ca.rlib(core-cd0ca85e71f914ca.0.o): In function `core::panicking::panic_fmt':
          /checkout/src/libcore/panicking.rs:69: undefined reference to `rust_begin_unwind'
          collect2: error: ld returned 1 exit status

I'm not doing anything special with regards to panics.

Print basic coverage

According to the tutorial, libfuzzer supports a -print_coverage=1 option to print out some basic coverage information.

This doesn't seem to work with cargo fuzz at the moment:

     Running `target/x86_64-unknown-linux-gnu/debug/fuzzer_script_1 -artifact_prefix=artifacts/ -max_len=200 -dict=dictionary.txt -print_coverage=1 corpus`
Dictionary: 10 entries
INFO: Seed: 1877614280
INFO: Loaded 0 modules (0 guards): 
Loading corpus dir: corpus
#0	READ units: 108
#108	INITED cov: 1584 corp: 83/10958b exec/s: 0 rss: 29Mb
#8192	pulse  cov: 1584 corp: 83/10958b exec/s: 4096 rss: 82Mb
#16384	pulse  cov: 1584 corp: 83/10958b exec/s: 5461 rss: 133Mb
#32768	pulse  cov: 1584 corp: 83/10958b exec/s: 5461 rss: 232Mb
#65536	pulse  cov: 1584 corp: 83/10958b exec/s: 6553 rss: 414Mb
^C==22321== libFuzzer: run interrupted; exiting
INFO: __sanitizer_symbolize_pc or __sanitizer_get_module_and_offset_for_pc is not available, not printing coverage

I'm not sure if this is the right way to get coverage or not, but it would certainly be interesting to see if there are any big chunks of my code that haven't been hit. (It's been 120 million runs since I last saw a new basic block, so I think this run has plateaued, and it's worth manually checking coverage now.)

Set up a corpus and artefact directory

Currently the artefacts are just dumped into the fuzz folder. We should create a corpus dir and pass it to the binary. We should also set up the -artefact-prefix arg

http://llvm.org/docs/LibFuzzer.html#options

-fsanitize-coverage=trace-cmp

According to the libfuzzer documentation, there's a -fsanitize-coverage=trace-cmp flag that looks interesting:

Tracing CMP instructions

With an additional compiler flag -fsanitize-coverage=trace-cmp (see SanitizerCoverageTraceDataFlow) libFuzzer will intercept CMP instructions and guide mutations based on the arguments of intercepted CMP instructions. This may slow down the fuzzing but is very likely to improve the results.

Value Profile

EXPERIMENTAL. With -fsanitize-coverage=trace-cmp and extra run-time flag -use_value_profile=1 the fuzzer will collect value profiles for the parameters of compare instructions and treat some new values as new coverage.

...

This feature has a potential to discover many interesting inputs, but there are two downsides. First, the extra instrumentation may bring up to 2x additional slowdown. Second, the corpus may grow by several times.

Is there any easy way to turn this on using cargo fuzz?

	fn dummy_target(script: &mut fs::File, pkg: &Package) -> Result<(), Box<error::Error>> {
	write!(script, r#"#![no_main]
	extern crate libfuzzer_sys;
	{}
	#[export_name="rust_fuzzer_test_input"]
	pub extern fn go(data: &[u8]) {{
	// fuzzed code goes here
	}}"#, link_to_lib(pkg).unwrap_or(String::new())).map_err(\|e\| e.into())
	}

rust-fuzz / cargo-fuzz Goto Github PK

cargo-fuzz's Introduction

cargo fuzz

Installation

Usage

cargo fuzz init

If your crate uses cargo workspaces, add fuzz directory to workspace.members in root Cargo.toml

cargo fuzz add <target>

cargo fuzz run <target>

cargo fuzz fmt <target> <input>

cargo fuzz tmin <target> <input>

cargo fuzz cmin <target>

cargo fuzz coverage <target>

Documentation

Trophy case

License

cargo-fuzz's People

Contributors

Stargazers

Watchers

Forkers

cargo-fuzz's Issues

Tracing CMP instructions

Value Profile

Recommend Projects

Recommend Topics

Recommend Org

`cargo fuzz`

`cargo fuzz init`

If your crate uses cargo workspaces, add `fuzz` directory to `workspace.members` in root `Cargo.toml`

`cargo fuzz add <target>`

`cargo fuzz run <target>`

`cargo fuzz fmt <target> <input>`

`cargo fuzz tmin <target> <input>`

`cargo fuzz cmin <target>`

`cargo fuzz coverage <target>`