Running `cargo afl fuzz` with no instrumentation (`-n`)

[vasumv]

I've been trying to run cargo afl fuzz without instrumentation (dumb mode) using the -n flag and I'm encountering the following:

[-] PROGRAM ABORT : Target's coverage map size of 466496 is larger than the one this AFL++ is set with (65536). Either set AFL_MAP_SIZE=466496 and restart  afl-fuzz, or change MAP_SIZE_POW2 in config.h and recompile afl-fuzz
         Location : afl_fsrv_start(), src/afl-forkserver.c:1100

I've set the AFL_MAP_SIZE to be larger than the target coverage map size, but I'm still encountering this error. I'm able to run cargo afl fuzz on this target normally. Any suggestions? Thanks for the help.

[smoelius]

@vasumv Could you share a link to the project you are fuzzing?

[vasumv]

I'm fuzzing a fairly large project called cedar, which may be fairly involved to reproduce. Here is a fork with my fuzz targets: https://github.com/vasumv/cedar-spec/tree/vasu/afl/cedar-drt/cedar-afl/src/fuzz_targets (instructions to build and run are in cedar-drt).

And here is the actual project that is being fuzzed: https://github.com/cedar-policy/cedar

Maybe a simpler place to start would be the tutorial url-fuzz-target example from the Rust fuzz book. While not the exact same issue, I'm noticing that cargo afl immediately times out on the dry run when the -n flag is enabled.

[-] The program took more than 1000 ms to process one of the initial test cases.
    This is bad news; raising the limit with the -t option is possible, but
    will probably make the fuzzing process extremely slow.

    If this test case is just a fluke, the other option is to just avoid it
    altogether, and find one that is less of a CPU hog.

[-] PROGRAM ABORT : Test case 'id:000000,time:0,execs:0,orig:url' results in a timeout
         Location : perform_dry_run(), src/afl-fuzz-init.c:1014

[vanhauser-thc]

There is no point in fuzzing with -n, will likely deprecate the option very soon…

[vasumv]

Depending on how the input generators are written, there may be a tradeoff between the instrumentation overhead and the benefits of coverage guidance.

I'd like to understand this tradeoff, so I was wondering if there's an option to run purely random input generation. It seems like -n is what I'd want; if it's being deprecated, is there any alternative that I could use?