Full libfuzzer shimming (for cargo-fuzz libfuzzer alternative and other use cases) #981

addisoncrump · 2023-01-03T22:48:27Z

So you want to fuzz some Rust code, eh? You can use the results of this PR by using cargo-fuzz and replacing the libfuzzer-sys dependency like so:

libfuzzer-sys = { version = "0.15.3", package = "libafl_libfuzzer" }

Adventurous users should pull from the latest git revisions:

libfuzzer-sys = { git = "https://github.com/AFLplusplus/LibAFL.git", package = "libafl_libfuzzer" }

Then simply use cargo-fuzz as normal. Some features are not available, but this should get you going with most fuzzing operations. Enjoy!

The original PR text is below.

Seeing as how libfuzzer has entered maintenance mode, we should provide a full libfuzzer alternative which stays up to date with modern fuzzing standards.

To this end, this PR seeks to offer libafl_libfuzzer, a full drop-in replacement for libfuzzer with support for the most common flags and sancov settings. Specifically, all of the things supported by cargo-fuzz. We can provide this shim to cargo-fuzz via environmental variable in libfuzzer-sys or, in the future, an init flag in cargo-fuzz itself.

We need to implement corpus merging (fairly straightforward with IndexesLenTimeMinimizingScheduler or cmin), crash minification (doable with tmin + InProcessForkExecutor), and a basic fuzzing runtime (optionally with dict support). cargo-fuzz uses many of the available sancov features, so we need some additional support for __san*cov items. As of writing, we have the following undefined references:

$ cargo fuzz build -s none |& grep -Eo "undefined reference to.*'" | sort -u 
undefined reference to `LLVMFuzzerMutate'
undefined reference to `__sancov_lowest_stack'
undefined reference to `__sanitizer_cov_pcs_init'
undefined reference to `__sanitizer_cov_trace_pc_indir'

I'm unfamiliar with __san*cov features, so I could use some help in developing that support.

I think this would be a good addition to the 0.9 release as well.

domenukk · 2023-01-04T13:39:36Z

LibAFL/fuzzers/libafl_atheris/src/lib.rs

Line 107 in d2985c5

pub fn LLVMFuzzerRunDriver(

Can we add support for the run FN and replace most of atheris, too?

libafl_targets/src/libfuzzer.rs

libafl_libfuzzer/libafl_libfuzzer_runtime/src/options.rs

addisoncrump · 2023-01-04T15:54:22Z

LibAFL/fuzzers/libafl_atheris/src/lib.rs

Line 107 in d2985c5

pub fn LLVMFuzzerRunDriver(

Can we add support for the run FN and replace most of atheris, too?

I'm unfamiliar with this aspect of the libfuzzer functionality. I'm sure we can replace it, though.

domenukk · 2023-01-04T16:01:13Z

LibAFL/fuzzers/libafl_atheris/src/lib.rs

Line 107 in d2985c5

pub fn LLVMFuzzerRunDriver(

Can we add support for the run FN and replace most of atheris, too?

I'm unfamiliar with this aspect of the libfuzzer functionality. I'm sure we can replace it, though.

It's a way for the target to start fuzzing at another point in time, so an own main, instead of using libfuzzer's main. We can probably move all code to this method and call this fn from a weak main

domenukk · 2023-01-04T18:20:04Z

AFLplusplus/AFLplusplus#1515

See this issue for the run method, too

libafl/src/mutators/scheduled.rs

libafl_libfuzzer/libafl_libfuzzer_runtime/src/fuzz.rs

domenukk · 2023-01-08T20:34:04Z

libafl_targets/src/sancov_cmp.c

+
+void __sanitizer_cov_trace_pc_indir(uintptr_t Callee) {
+    // unused
+    // TODO implement


Reading through the documentation at https://clang.llvm.org/docs/SanitizerCoverage.html#tracing-pcs-with-guards it looks like this is pretty straight forward, we just want a portion of the coverage map for indirect branches and then map them as feedback.
Also, it looks like the function is called __sanitizer_cov_trace_pc_indirect(void *callee) in newer compilers (or in some versions and the docs are old?) so maybe we want to export both

domenukk · 2023-01-09T11:19:20Z

libafl_targets/src/libfuzzer.c

+// take a page out of libfuzzer's book: static define __sancov_lowest_stack
+// since we don't support it yet
+// TODO support it
+MAYBE_THREAD_LOCAL uintptr_t __sancov_lowest_stack;


Support can be as easy as exposing this value to rust via an fn - then we can build an observer that observes stack depth of a run, quasi for free

libafl/src/corpus/testcase.rs

libafl_libfuzzer/libafl_libfuzzer_runtime/src/fuzz.rs

libafl/src/corpus/ondisk.rs

Mrmaxmeier · 2023-01-19T10:11:35Z

Hi,
I wanted to try this but I'm seeing a bunch of "multiple definition" linker errors for Rust runtime symbols (__rdl_alloc, rust_eh_personality, ...).
I'm setting CUSTOM_LIBFUZZER_PATH to <LibAFL>/target/debug/build/libafl_libfuzzer-00bdb9ec1c4f4eed/out/runtime-target/x86_64-unknown-linux-gnu/release/libafl_libfuzzer_runtime.a (without the rust-fuzz/libfuzzer#103 fix applied).

Am I holding it wrong? (Compiling to a cdylib instead of staticlib or using the .rlib instead of the .a doesn't seem to work either)

addisoncrump · 2023-01-19T10:18:55Z

Hey, thanks for giving this a go. Try building it from within libafl_libfuzzer_runtime directly instead? It sounds like what your doing should work, so if you're still having issues I can investigate with you in Discord. Also, make sure you're building with the same toolchain as your default (e.g., avoid +nightly or +stable flags, I haven't sorted out a bug there just yet).

Mrmaxmeier · 2023-01-19T10:51:04Z

Building libafl_libfuzzer_runtime directly works 👍
The -Zbuild-std line in the wrapper build script seems to break stuff on my machine 🤷

addisoncrump · 2023-02-13T18:16:50Z

07abe31 is blocked by #1067

libafl_libfuzzer/libafl_libfuzzer_runtime/src/feedbacks.rs

tokatoka · 2023-08-22T17:35:11Z

libafl_libfuzzer/libafl_libfuzzer_runtime/src/fuzz.rs

+            Option<StdState<_, _, _, _>>,
+            SimpleRestartingEventManager<_, StdState<_, _, _, _>, _>,
+        ) = match SimpleRestartingEventManager::launch(monitor, &mut shmem_provider) {
+            // The restarting state will spawn the same process again as child, then restarted it each time it crashes.


i guess if you launch the manager everytime, then the timestamp is not preserved across restarts

Maybe fix this after merging/open an issue?

domenukk · 2023-08-22T23:34:15Z

error[E0133]: call to unsafe function is unsafe and requires unsafe function or block
   --> libafl/src/schedulers/probabilistic_sampling.rs:192:13
    |
192 |             libafl_bolts::serdeany::RegistryBuilder::register::<super::ProbabilityMetadata>();
    |             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ call to unsafe function
    |
    = note: consult the function's documentation for information on how to avoid undefined behavior

error: aborting due to previous error

Seems like we're close, though

jasikpark · 2023-08-24T21:12:11Z

🥳

ndrewh · 2024-02-21T22:39:46Z

      Finished release [optimized + debuginfo] target(s) in 4m 21s
  LLVM ERROR: Invalid encoding
  thread 'main' panicked at 'Couldn't create runtime archive!', libafl_libfuzzer/build.rs:86:9
  note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
error: process didn't exit successfully: `/home/runner/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/bin/cargo check --manifest-path libafl_libfuzzer/Cargo.toml --no-default-features --features whole-archive` (exit status: 101)
Error: Process completed with exit code 1.

That's a new one..

@addisoncrump any ideas how to fix this?

I ran into this. It turns out that nm behavior differs depending on your system LLVM, and that uninstalling your system LLVM fixes the issue.

backtrace to the error (TIL that nm just invokes your system LLVM)

#5  0x00007fffe898d723 in llvm::report_fatal_error(llvm::Twine const&, bool) () from /lib/x86_64-linux-gnu/libLLVM-14.so.1
#6  0x00007fffe898d556 in llvm::report_fatal_error(char const*, bool) () from /lib/x86_64-linux-gnu/libLLVM-14.so.1
#7  0x00007fffe94a79ca in llvm::BitstreamCursor::ReadAbbrevRecord() () from /lib/x86_64-linux-gnu/libLLVM-14.so.1
#8  0x00007fffe942dfce in ?? () from /lib/x86_64-linux-gnu/libLLVM-14.so.1
#9  0x00007fffe94341bd in llvm::getBitcodeFileContents(llvm::MemoryBufferRef) () from /lib/x86_64-linux-gnu/libLLVM-14.so.1
#10 0x00007fffea0efc75 in llvm::object::readIRSymtab(llvm::MemoryBufferRef) () from /lib/x86_64-linux-gnu/libLLVM-14.so.1
#11 0x00007fffe9f663d2 in llvm::lto::InputFile::create(llvm::MemoryBufferRef) () from /lib/x86_64-linux-gnu/libLLVM-14.so.1
#12 0x00007fffee4ed22a in ?? () from /usr/bin/../bin/../lib/bfd-plugins/LLVMgold-14.so
#13 0x00007ffff7f497c2 in ?? () from /lib/x86_64-linux-gnu/libbfd-2.38-system.so
#14 0x00007ffff7f49a1c in ?? () from /lib/x86_64-linux-gnu/libbfd-2.38-system.so
#15 0x00007ffff7e8790c in bfd_check_format_matches () from /lib/x86_64-linux-gnu/libbfd-2.38-system.so

I made the grave error of having LLVM 14 installed on my machine. Uninstalling LLVM 14 fixed the issue -- libbfd instead chose the LLVMgold-15.so plugin (nope -- i have no idea where it makes this decision) which... uhhh... doesn't seem to invoke my system LLVM at all and prints the symbols successfully.

tokatoka · 2024-02-21T22:52:09Z

Some symbols we are using in libafl_libfuzzer are missing in LLVM 14, so it doesn't work on llvm <= 14

ndrewh · 2024-02-22T04:36:51Z

@tokatoka I think you misunderstand. build.rs invokes nm, which was hitting an error depending on the system LLVM:

  LLVM ERROR: Invalid encoding

Ideally, the behavior of this crate would not depend on whether or not /lib/x86_64-linux-gnu/libLLVM-14.so.1 exists on the system. (note: /lib/x86_64-linux-gnu/libLLVM-15.so.1 also exists on the system). IMO this is probably an upstream issue, but we probably shouldn't be using the system nm here to begin with.

ndrewh · 2024-02-22T04:40:38Z

In theory i think the llvm-nm that ships with cargo's llvm-tools component should work, but it hits a different encoding error regardless of system LLVM.

tokatoka · 2024-02-22T07:45:00Z

my point is even if you avoid that issue, the fuzzer wouldn't have linked using llvm 14.

AaronFriel · 2025-09-09T01:14:22Z

@addisoncrump how could I improve the documentation with how to fuzz?

I ask because the pointers here are a little convoluted on how to answer the question "how do I fuzz Rust in 2025?"

One might find "cargo fuzz", but evidently it depends on libfuzzer and is no longer supported. Bummer.

If one finds https://github.com/AFLplusplus/cargo-libafl, it's archived and no longer supported. It links to this pull request instead of... a CLI.

The PR body doesn't describe how to use this, but more digging finds that the current wisdom is use cargo fuzz with this dependency entry:

libfuzzer-sys = { version = "0.15.3", package = "libafl_libfuzzer" }

But I can't actually find that anywhere except in GitHub code search.

Could you add that to your PR body (because it ends up being one of the strange attractors in this. It's a bit unfortunate but there's basically no documentation online that just explicitly says what to do.

This PR though ends up being linked to via cargo-libafl and some blog posts, link aggregators, etc.

addisoncrump · 2025-09-09T18:33:03Z

But I can't actually find that anywhere except in GitHub code search.

Oh, that's annoying. It's actually in the libafl_libfuzzer documentation, but docs.rs builds haven't been working for a while...

I think part of the solution might be to ask the cargo-fuzz folks to also add us to their README. But you are correct: we should document this better. I've added a short TL;DR to this PR.

addisoncrump self-assigned this Jan 3, 2023

domenukk reviewed Jan 4, 2023

View reviewed changes

libafl_targets/src/libfuzzer.rs Outdated Show resolved Hide resolved

domenukk reviewed Jan 4, 2023

View reviewed changes

libafl_libfuzzer/libafl_libfuzzer_runtime/src/options.rs Outdated Show resolved Hide resolved

domenukk reviewed Jan 8, 2023

View reviewed changes

libafl/src/mutators/scheduled.rs Show resolved Hide resolved

libafl_libfuzzer/libafl_libfuzzer_runtime/src/fuzz.rs Outdated Show resolved Hide resolved

libafl_libfuzzer/libafl_libfuzzer_runtime/src/fuzz.rs Outdated Show resolved Hide resolved

domenukk reviewed Jan 8, 2023

View reviewed changes

libafl_libfuzzer/libafl_libfuzzer_runtime/src/fuzz.rs Outdated Show resolved Hide resolved

domenukk reviewed Jan 8, 2023

View reviewed changes

addisoncrump force-pushed the libfuzzer branch from 9887e0e to ddf796d Compare January 8, 2023 23:34

domenukk reviewed Jan 9, 2023

View reviewed changes

libafl/src/corpus/testcase.rs Outdated Show resolved Hide resolved

domenukk reviewed Jan 9, 2023

View reviewed changes

libafl/src/corpus/testcase.rs Outdated Show resolved Hide resolved

addisoncrump force-pushed the libfuzzer branch from ddf796d to db60f2d Compare January 18, 2023 06:33

domenukk reviewed Jan 18, 2023

View reviewed changes

libafl_libfuzzer/libafl_libfuzzer_runtime/src/fuzz.rs Outdated Show resolved Hide resolved

addisoncrump force-pushed the libfuzzer branch from e9ca5b4 to 96800bf Compare January 18, 2023 11:07

domenukk reviewed Jan 18, 2023

View reviewed changes

libafl/src/corpus/ondisk.rs Outdated Show resolved Hide resolved

addisoncrump force-pushed the libfuzzer branch from eea1d3a to c6e5112 Compare January 18, 2023 22:59

addisoncrump force-pushed the libfuzzer branch 2 times, most recently from 072a665 to 9603940 Compare January 25, 2023 15:57

addisoncrump force-pushed the libfuzzer branch from 60ed625 to b4cc3fb Compare February 10, 2023 18:20

addisoncrump force-pushed the libfuzzer branch 4 times, most recently from 10f4099 to e36f5a6 Compare February 20, 2023 17:11

domenukk reviewed Aug 22, 2023

View reviewed changes

libafl_libfuzzer/libafl_libfuzzer_runtime/src/feedbacks.rs Show resolved Hide resolved

addisoncrump added 6 commits August 22, 2023 13:57

clippy :cursed_cowboy:

ae4686c

attempt to fix wasm

d5b39e8

spooky unknowable bug 👻

cf0e1ef

more clippy lints

ebe961d

clippy fix for merge

0122a03

use the version pin

f6d225c

tokatoka reviewed Aug 22, 2023

View reviewed changes

domenukk and others added 7 commits August 23, 2023 08:30

Merge branch 'main' into libfuzzer

d5d654e

add unsafe to ::register

b7e2752

Serdeany autoreg fix

9020704

make type assert actionable

ff23e2b

miri fixes

672137c

Merge branch 'main' into libfuzzer

49718c8

Merge branch 'main' into libfuzzer

aefcb82

domenukk mentioned this pull request Aug 24, 2023

Libafl_libfuzzer: Timestamps are not preserved across crashes/timeouts #1455

Closed

domenukk merged commit 862de53 into main Aug 24, 2023

domenukk deleted the libfuzzer branch August 24, 2023 11:30

tokatoka mentioned this pull request Nov 7, 2023

Building libfuzzer_stb_image on Windows #1652

Closed

crepererum mentioned this pull request Jan 25, 2024

Fuzz tests for Arrow/Parquet apache/arrow-rs#5332

Open

EliaGeretto mentioned this pull request Aug 22, 2025

InMemoryOnDiskCorpus::with_meta_format_and_prefix does not actually add a prefix to files #3404

Open

Uh oh!

Full libfuzzer shimming (for cargo-fuzz libfuzzer alternative and other use cases) #981

Full libfuzzer shimming (for cargo-fuzz libfuzzer alternative and other use cases) #981

Uh oh!

Conversation

addisoncrump commented Jan 3, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

domenukk commented Jan 4, 2023

Uh oh!

Uh oh!

Uh oh!

addisoncrump commented Jan 4, 2023

Uh oh!

domenukk commented Jan 4, 2023

Uh oh!

domenukk commented Jan 4, 2023

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

domenukk Jan 8, 2023

Choose a reason for hiding this comment

Uh oh!

domenukk Jan 9, 2023

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Mrmaxmeier commented Jan 19, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

addisoncrump commented Jan 19, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Mrmaxmeier commented Jan 19, 2023

Uh oh!

addisoncrump commented Feb 13, 2023

Uh oh!

Uh oh!

tokatoka Aug 22, 2023

Choose a reason for hiding this comment

Uh oh!

domenukk Aug 22, 2023

Choose a reason for hiding this comment

Uh oh!

domenukk commented Aug 22, 2023

Uh oh!

jasikpark commented Aug 24, 2023

Uh oh!

ndrewh commented Feb 21, 2024

Uh oh!

tokatoka commented Feb 21, 2024

Uh oh!

ndrewh commented Feb 22, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ndrewh commented Feb 22, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

tokatoka commented Feb 22, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

AaronFriel commented Sep 9, 2025

Uh oh!

addisoncrump commented Sep 9, 2025

Uh oh!

Uh oh!

addisoncrump commented Jan 3, 2023 •

edited

Loading

Mrmaxmeier commented Jan 19, 2023 •

edited

Loading

addisoncrump commented Jan 19, 2023 •

edited

Loading

ndrewh commented Feb 22, 2024 •

edited

Loading

ndrewh commented Feb 22, 2024 •

edited

Loading

tokatoka commented Feb 22, 2024 •

edited

Loading