google / fuzzer-test-suite Goto Github PK

Set of tests for fuzzing engines

License: Apache License 2.0

Shell 0.54% C++ 0.39% C 99.08%

fuzzer-test-suite's Introduction

fuzzer-test-suite

⚡ NOTE: For most use cases, fuzzer-test-suite is superseded by FuzzBench. We recommend using FuzzBench for all future fuzzer benchmarking. FuzzBench is based on many of the same ideas as FTS, such as realistic benchmarks (it actually uses some benchmarks from FTS) but has many improvements such as a free service and a design that makes adding new fuzzers and new benchmarks easier.

This is a set of tests (benchmarks) for fuzzing engines (fuzzers).

The goal of this project is to have a set of fuzzing benchmarks derived from real-life libraries that have interesting bugs, hard-to-find code paths, or other challenges for bug finding tools.

The current version supports libFuzzer and AFL. In future versions we may support other fuzzing engines.

Contributing

See CONTRIBUTING first. If you want to add one more benchmark to the test suite, simply mimic one of the existing benchmarks and send the pull request.

Disclaimer

This is not an official Google product.

fuzzer-test-suite's People

Contributors

Stargazers

Watchers

Forkers

wflk chubbymaggie adambacchus riverhac jackhuyh 0xr0ot happilycoded terry2012 lucabongiorni ht13 sevck n0z3r0 kernullist ieswxia kcc yangy-xiao lxpe inarcissuss epeius enovella alexxnica krodyx antonioyip jijicanyu sunjieee kuteminh11 deelmind sage-pe duzhanyuan zhouat yangronghai ptgeek zhuceyongdela1234 edmcman hiaeia dnoursi woonhak alxsoares readercrap farahhariri freetimex tarkany thelongestusernameofall nettrino ifarhankhan wzugang yujokang ronakodhaviya bestshow idkwim sky8336 thomasking2014 myvyang somebody365 ele7enxxh wsygoogol xbalien takboo mambaboy hanshaze henices bshastry bjblcracked xp0int austinsmom bt123 nevinhappy arsense nimdakey geekwish nimishb clccc antbean 0xsunsama de8gman1990 houcy prashantbarca morehouse allpaca dgotrik cseq beduin23 ufwt we4p0x expertasif xiongzhouwulie paulmenzel sigma-random cheeseharry youngcraft tracesrc changsongzhu nudtmao hawking2013 butterflyhack byteways heli-automotive cd3l3on d3viluke znqt

fuzzer-test-suite's Issues

Fuzzing the JIT compiler of V8

Hello,
I am currently working on a project that involves fuzzing JIT compilers. I am looking into libFuzzer and was trying to figure out how I can use libFuzzer to fuzz the JIT compiler engines of V8. I could not find any tutorials or documentation that talked about integrating libFuzzer with V8 and JIT compilers in specific.

I was wondering if there are any resources I can look into to understand how I can use libFuzzer (or any other fuzzer such as oss-fuzz or jfs) to fuzz the JIT compilers of V8.

Thanks!

Build issues on i386

The png mutator fails to build on i386 (google/oss-fuzz#2702 (comment))

build log (https://travis-ci.org/google/oss-fuzz/jobs/572768764#L544):

In file included from <built-in>:1:

./../fuzzer-test-suite/libpng-1.2.56/png_mutator.h:240:11: error: no matching function for call to 'uncompress'

          uncompress(v.data(), &len, compressed.data(), compressed.size());

          ^~~~~~~~~~

/usr/include/zlib.h:1197:21: note: candidate function not viable: no known conversion from 'size_t *' (aka 'unsigned int *') to 'uLongf *' (aka 'unsigned long *') for 2nd argument

ZEXTERN int ZEXPORT uncompress OF((Bytef *dest,   uLongf *destLen,

                    ^

In file included from <built-in>:1:

./../fuzzer-test-suite/libpng-1.2.56/png_mutator.h:256:11: error: no matching function for call to 'compress'

          compress(v.data(), &len, uncompressed.data(), uncompressed.size());

          ^~~~~~~~

/usr/include/zlib.h:1160:21: note: candidate function not viable: no known conversion from 'size_t *' (aka 'unsigned int *') to 'uLongf *' (aka 'unsigned long *') for 2nd argument

ZEXTERN int ZEXPORT compress OF((Bytef *dest,   uLongf *destLen,

the openthread benchmark doesn't build with the latest clang

./thread/mle_tlvs.hpp:103:9: error: declaration shadows a variable in namespace 'ot::Mle' [-Werror,-Wshadow]
        kVersion             = 18, ///< Version TLV
        ^
./thread/mle_constants.hpp:60:5: note: previous declaration is here
    kVersion                       = 2,     ///< MLE Version
    ^

Where should I ask questions about libFuzzer core?

I'm interested in moving the instrumentation data generated by LibFuzzer to a memory-mapped page so that I can fuzzer multi-processed applications.

Who should I talk to about this?

Thanks!
Willem

libarchive requires XML

Must ensure that installing libxml2 in tutorial/install-deps.shdoesn't interfere with the xml benchmark

why is there the occasional indent on fuzzer output?

Sometimes my fuzzing output looks like this:

#542092	REDUCE cov: 123 ft: 316 corp: 129/10278b exec/s: 33880 rss: 305Mb L: 112/160 MS: 1 EraseBytes-
#581101	REDUCE cov: 123 ft: 316 corp: 129/10277b exec/s: 34182 rss: 305Mb L: 117/160 MS: 4 ShuffleBytes-EraseBytes-ChangeBit-CopyPart-
#614693	REDUCE cov: 123 ft: 316 corp: 129/10272b exec/s: 34149 rss: 305Mb L: 112/160 MS: 2 ChangeASCIIInt-CrossOver-
#797995	REDUCE cov: 123 ft: 316 corp: 129/10271b exec/s: 33249 rss: 305Mb L: 112/160 MS: 2 CMP-EraseBytes- DE: "\xf1\x00\x00\x03"-
#828678	REDUCE cov: 123 ft: 316 corp: 129/10270b exec/s: 33147 rss: 305Mb L: 112/160 MS: 3 InsertRepeatedBytes-CrossOver-EraseBytes-
#930754	REDUCE cov: 123 ft: 316 corp: 129/10266b exec/s: 33241 rss: 306Mb L: 118/160 MS: 1 EraseBytes-
#1048576	pulse  cov: 123 ft: 316 corp: 129/10266b exec/s: 32768 rss: 306Mb
#1288761	REDUCE cov: 123 ft: 316 corp: 129/10264b exec/s: 31433 rss: 306Mb L: 113/160 MS: 2 ChangeByte-EraseBytes-
#1288829	REDUCE cov: 123 ft: 316 corp: 129/10263b exec/s: 31434 rss: 306Mb L: 112/160 MS: 3 EraseBytes-ChangeByte-CopyPart-
#1309196	REDUCE cov: 123 ft: 316 corp: 129/10262b exec/s: 31931 rss: 306Mb L: 112/160 MS: 2 ShuffleBytes-EraseBytes-
#1423088	REDUCE cov: 123 ft: 316 corp: 129/10261b exec/s: 31624 rss: 306Mb L: 112/160 MS: 2 EraseBytes-ChangeASCIIInt-
#1732694	REDUCE cov: 123 ft: 316 corp: 129/10260b exec/s: 32086 rss: 306Mb L: 112/160 MS: 1 CrossOver-

Why is that indent occurring?

Use rsync in begin-experiment.sh

Replace scp with rsync. May require a startup script on the dispatcher to use gsutils.

What to A/B test

Let's collect a list of things we want to A/B compare.
(Update this note instead of adding more comments)

libFuzzer vs AFL (later: vs hoggfuzz?)
libFuzzer vs libFuzzer
- -fsanitize=fuzzer vs -fsanitize-coverage=trace-pc-guard,trace-cmp,trace-gep,trace-div
- -reduce_inputs 0 vs 1
- -shrink 0 vs 1
- -use_value_profile 0 vs 1
- -cross_over 0 vs 1
- -mutate_depth (values between 0 and 100)
- -reduce_depth 0 vs 1
- -use_counters 0 vs 1
- -use_memmem 0 vs 1
- -use_cmp 0 vs 1
- -use_feature_frequency 0 vs 1
- -experimental_len_control 0 vs 1000 vs 10000 vs 100000
- w/ and w/o stack depth signal
- use_clang_coverage 0 vs 1 (with and w/o clang coverage insrumentation
- use other distance metric for value profiles, e.g. |x-y| instead of hamming(x, y)
- use unsigned integer overflow as a coverage signal

How Can I Use FTS?

Hello,
Is there a instruction?
Fuzzbench is not for me.
I want to fuzz FTS.
Thanks.

use "-libfuzzer" suffix for libFuzzer binaries

Currently we build binaries like "foo" (libFuzzer) and "foo-afl" (afl).
Instead they should be "foo-libfuzzer" and "foo-afl".
The change should be made at least in common.sh, all test-libfuzzer.sh, and in the tutorial text.

support plain 'coverage' build

in addition to libfuzzer and afl we need to support a plain coverage build that can be used to produce a simple coverage dump.

Usage example

==> cond.c <==
void foo(long *a) {
  if (a)
    *a = 0;
}

==> cond_main.c <==
void foo(long *a);
int main(int argc, char **argv) {
  long a;
  foo(argc > 1 ? &a : 0);
}

% clang -g -O1 cond.c cond_main.c -fsanitize-coverage=trace-pc-guard
% UBSAN_OPTIONS=coverage=1  ./a.out
SanitizerCoverage: ./a.out.2499.sancov: 3 PCs written
% UBSAN_OPTIONS=coverage=1  ./a.out 1 
SanitizerCoverage: ./a.out.2501.sancov: 3 PCs written
% sancov.py print ./a.out.2499.sancov
sancov.py: read 3 64-bit PCs from ./a.out.2499.sancov
sancov.py: 1 file merged; 3 PCs total
0x41e82d
0x41e84f
0x41e890
% sancov.py print ./a.out.2501.sancov
sancov.py: read 3 64-bit PCs from ./a.out.2501.sancov
sancov.py: 1 file merged; 3 PCs total
0x41e82d
0x41e83c
0x41e890
% sancov.py merge ./a.out.2499.sancov ./a.out.2501.sancov > merged.sancov
sancov.py: read 3 64-bit PCs from ./a.out.2499.sancov
sancov.py: read 3 64-bit PCs from ./a.out.2501.sancov
sancov.py: 2 files merged; 4 PCs total
% sancov.py print merged.sancov 
sancov.py: read 4 32-bit PCs from merged.sancov
sancov.py: 1 file merged; 4 PCs total
0x41e82d
0x41e83c
0x41e84f
0x41e890

A/B test libFuzzer: simplify CFGs vs. don't simplify CFGs

We need to evaluate the usefulness of disabling CFG simplification under sanitizer_coverage instrumentation. Simplifying CFGs should make code faster and therefore allow more executions per second. But simplifying CFGs also reduces the signal we get from comparison instrumentation.

See google/sanitizers#893.

GCloud concurrency

For somewhat mysterious reasons, using & to send gcloud commands such as gcloud compute instances create to the background totally breaks the gcloud functionality. This should be debugged and resolved.

About original seeds

I noticed that that some programs has original input seeds such as boringssl.
But there are some programs that do not have original seeds like re2.
Would you help to produce some seeds as the original input?

Harfbuzz has dependency: ragel

It seems like ragel belongs in tutorial/install-deps.sh

main() function

After reviewing this fuzzer, I'm not sure I can use it. I can't initialize my program without a function that is run after global constructors. So I need libfuzzer to provide me a weak function I can override that will be a second main to fuzzer but a primary main to me. I don't care about program arguments. Again, I need to run a main-like function after global constructors, otherwise it's all up to random chance.
How is this solved?

Second issue: No tutorial or documentation mentions that int main() is already provided.

add crash inputs for openthread

openthread had a few stack-buffer-overflows in the past.
Please add all crash inputs and document which revisions are required to trigger the crashes.

`*.sancov` files not generated when fuzzing woff2

I wanted to get the sancov coverage files generated using the default ASAN hooks for the guard functions and was invoking it by first building with the appropriate flags inside Docker using the base image libfuzzertutorial/base:

# ~/FTS/woff2-2016-05-06/build.sh asan
# ASAN_OPTIONS=coverage=1 ./woff2-2016-05-06-libfuzzer

The fuzzer by itself is working fine and I can see it discovering new paths. However, no sancov files are generated which should be if the guard hooks were being hit. Is there anything that I might be doing wrong?

verify that the openthread benchmark can detect old bugs

I've tried using the openthread-2018-02-27 (with various revisions of the openthread git repo)
to reproduce one of the previously reported bugs and none were detected.

Please check why.

One thing I noted is that we are not using -DFUZZING_BUILD_MODE_UNSAFE_FOR_PRODUCTION (and we should, for all benchmarks), but there is probably something else too.

more benchmarks

Let's keep this issue as a TODO list for adding new benchmarks.
For the interesting oss-fuzz bugs we can add them only once the bugs become public.

[Feature-Request] Benchmark Performance/Effectiveness of Different Build Flags

It is unclear which build flags are best for fuzzing. libFuzzer (apparently) recommends -O1 while AFL automatically uses -O3 -funroll-loops

It would be awesome to have data on which build options are best.
Would it be possible to have a benchmark that compared engines on fuzz targets built using different flags?

Can I add my own fuzzers to compare?

I see that AFL, Libfuzzer and Libfuzzer's FsanitizeFuzzer are supported. Does this mean that if I write a config file that sets the engine to Hongfuzz, for example, I won't be able to run it because there's no support?

Basically, my question is: does the config file only recognize AFL and Libfuzzer as valid engines?

Are there other strategies for mitigating OOM lag?

I'm using libFuzzer to fuzz an API.
The API is deserializing an array of bits (given by libFuzzer)
and converting them into c++ class instantiations.

Due to the serialization format, libFuzer is able construct a serialized object that tell the deserializer to reserve large amounts of data which cannot be meet.
This is done through calls to std::vector::resize(). The vector throws a std::bad_alloc, and although the problem is caught and safely mitigated, it causes extreme lag in the fuzzer (as mentioned in the following documentation).

In an attempt to lower the amount of memory used when the fuzzer is running, I was hoping to set ulimit -v and adjust the available virtual memory of the process. My thought was, even though it will still be hitting OOM errors, it will be at a lower memory cap, and that will mitigate delays?

However doing so causes

==27609==ERROR: AddressSanitizer failed to allocate 0xdfff0001000 (15392894357504) bytes at address 2008fff7000 (errno: 12)
==27609==ReserveShadowMemoryRange failed while trying to map 0xdfff0001000 bytes. Perhaps you're using ulimit -v

Why can't the address sanitizer work under ulmit -v? (SO)
If I could, maybe I would be able to fuzz more effectively. Or maybe that's the wrong approach anyway.

The build flags I'm using are:

    copts = [
        "-fsanitize=address,fuzzer",
        "-fsanitize-trap=undefined,integer",
        "-fsanitize-coverage=trace-pc,trace-cmp,trace-pc-guard",
        "-g",
        "-O0",
        "-fno-omit-frame-pointer",
        "-fno-sanitize=vptr",
    ],
    linkopts = [
        "-fsanitize=address,fuzzer",
        "-fsanitize-trap=undefined,integer",
        "-fno-sanitize=vptr",
        "-fsanitize-link-c++-runtime",
    ],

I tried turning flags off so I could set ulimit and run the fuzzer:

copts = [
    "-fsanitize=fuzzer",
    "-g",
    "-O0",
    "-fno-omit-frame-pointer",
],
linkopts = [
    "-fsanitize=fuzzer",
],

but this causes an immediate segfault.

Do you have any advice for me?
I wish setting -rss_limit_mb and -malloc_limit_mb, didn't cause the fuzzer to stop. I guess I'll have to find a better approach to converting raw bits into c++ instances. I know there is like a protobuff glue API or something, but I'm working under a different IDL.

I don't really want to change the implementation, but maybe
I could use FUZZING_BUILD_MODE_UNSAFE_FOR_PRODUCTION and just try to do extra checking and contraining in the implementation to avoid large allocs.

I'm just wondering if you have any thoughts or experience in handling APIs like this?

migrate tutorial.libfuzzer.info to http://apt.llvm.org/

change tutorial/install-clang.sh to get fresh clang instead of 5.0
change the build.sh scripts to use -fsanitize=fuzzer[-no-link] by default.

evaluate libFuzzer's -fork=1 mode

Matt, please try to evaluate -fork=0 (default) vs -fork=1 using the fresh clang

Fuzzing IP stack

I'm currently fuzzing an IP stack written in modern C++, and I recently added a way to "apply" payloads. Only one payload is not always enough to trigger the crash, so I was wondering what your thoughts are on this? What if the fuzzer could dump the last X payloads?

Example:

 +--> WARNiNG: Environment unsafe for production
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    [ Network ] Creating stack for UserNet on eth0 (MTU=4000)
       [ Inet ] Bringing up eth0 on CPU 0
       [ Inet ] Network configured (01:02:03:04:05:06)
                IP: 		10.0.0.42
                Netmask: 	255.255.255.0
                Gateway: 	10.0.0.1
                DNS Server: 	10.0.0.1
    [ Network ] Creating stack for UserNet on eth1 (MTU=4000)
       [ Inet ] Bringing up eth1 on CPU 0
       [ Inet ] Network configured (01:02:03:04:05:06)
                IP: 		10.0.0.43
                Netmask: 	255.255.255.0
                Gateway: 	10.0.0.1
                DNS Server: 	10.0.0.1
*** Inserting payload crash-ac14c3b630c779e70d5e47363ca5d48842c9704f into stack...
ip4: Ignored checksum on packet
*** Payload crash-ac14c3b630c779e70d5e47363ca5d48842c9704f was inserted into stack

Not crashing!

Investigate effect of AFL_I_DONT_CARE_ABOUT_MISSING_CRASHES=1

We need to determine whether the above environment variable causes AFL to suppress crashes that we need to detect. If so, engine-comparison/runner.sh needs to be updated and we need to configure /proc/sys/kernel/core_pattern on the VMs instead.

update the front page to reflect that we have engine comparison and support AFL

subj

A/B testing for fuzzing engines

Let's keep the work-in-progress design of A/B testing tool at docs/ab-testing.md and use this bug to track the progress.

Consider using --preemptible instances

The build script for boringssl breaks when overriding CFLAGS and CXXFLAGS

The build script for boringssl is currently not linking pthread. The -lpthread argument is missing from this line. That argument is required when using the static build, as you can see here.

This problem is fixed by the second commit in #155. Please, consider merging it.

How much memory is recommended/required for the test suite?

Running into a lot of AddressSanitizer: allocator is out of memory trying to allocate 0x1000 bytes and ERROR: Failed to mmap errors and I'm wondering if it is the compilation or the machine. I'm using a 2GB no SWAP and 1 vCore cloud instance. What would you recommend?

structure-aware-fuzzing

Hello,

Just a quick question regarding the "structure-aware-fuzzing" note. Isn't it a variant of grammar-aware (white/grey) box fuzzing?

[1] https://arxiv.org/pdf/1812.01197.pdf
[2]https://people.csail.mit.edu/akiezun/pldi-kiezun.pdf

Buggy line of sqlite

May I ask what is the buggy line of sqlite? There are three bugs in the benchmark, but when I open the bug report, it does not show the buggy line of each bug.

support -fsanitize=fuzzer

Fresh clang supports -fsanitize=fuzzer (and e.g. -fsanitize=address,fuzzer)
which is now the preferred way for a user to build/link with libFuzzer.
It includes both the compile-time flags (-fsanitize-coverage=...) and link-time flags (linking with libFuzzer).

We need to support -fsanitize=fuzzer as one of the of fuzzing engines.

Help to understand libFuzzer

Hi, I am totally new to fuzzing and also to libFuzzer. I have successfully setup and run this tutorial and seen desired outputs. But I want to know the internal working, especially the how to generate data and its size and then give these arguments to our function under test.

bool FuzzMe(const uint8_t *Data, size_t DataSize) {
  return DataSize >= 3 &&
      Data[0] == 'F' &&
      Data[1] == 'U' &&
      Data[2] == 'Z' &&
      Data[3] == 'Z';  // :‑<
}

extern "C" int LLVMFuzzerTestOneInput(const uint8_t *Data, size_t Size) {
  FuzzMe(Data, Size);
  return 0;
}

So how (and what ) the values for Data pointer and Size are generated ?
in FuzzMe function, we are checking that DataSize should be >= (greater than or equal to) 3. In this it should not be a bug, because it also valid >3... why its a bug at Data[3]='Z' ?

where is libFuzzingEngine-libfuzzer.a in libjpeg-turbo-07-2017

When I ran the build.sh in libjpeg-turbo-07-2017, I got such result. But I cannot find the libFuzzingEngine-libfuzzer.a neither in SRC nor BUILD.

+ clang++ -O2 -fno-omit-frame-pointer -gline-tables-only -fsanitize=address -fsanitize-address-use-after-scope -fsanitize-coverage=trace-pc-guard,trace-cmp,trace-gep,trace-div -std=c++11 ../libjpeg_turbo_fuzzer.cc -I BUILD BUILD/.libs/libturbojpeg.a libFuzzingEngine-libfuzzer.a -o ..-libfuzzer
clang-4.0: error: no such file or directory: 'libFuzzingEngine-libfuzzer.a'

Did I run such project in a wrong way?

cd fuzzer-test-suite/libjpeg-turbo-07-2017/
mkdir tmp
cd tmp
bash ../build.sh asan

Compilation error

Hi. I'm trying to test the Fuzzer Test Suite with AFL, and here are the changes I made to the two script files. After making the changes, I tried compiling each file with build.sh. However, the compilation error is shown in bold at the end. How can I fix it?

#FUZZING_ENGINE=${FUZZING_ENGINE:-"fsanitize_fuzzer"}
FUZZING_ENGINE=${FUZZING_ENGINE:-"afl"}

#AFL_SRC=${AFL_SRC:-$(dirname $(dirname $SCRIPT_DIR))/AFL}
AFL_SRC=${AFL_SRC:-/AFL-master}

#export CC=${CC:-"clang"}
#export CXX=${CXX:-"clang++"}
export CC=${CC:-"afl-clang-fast"}
export CXX=${CXX:-"afl-clang-fast++"}

Building with afl
afl-clang-fast 2.57b by [email protected]
afl-llvm-pass 2.57b by [email protected]
[+] Instrumented 64 locations (non-hardened mode, ratio 100%).
inlinable function call in a function with debug info must have a !dbg location
call void @__sanitizer_cov_trace_pc_guard(i32 inttoptr (i64 add (i64 ptrtoint ([22 x i32] @_sancov_gen.7 to i64), i64 80) to i32*)) #14**

migrate the tutorial to LLVM 6.0 (and -fsanitize=fuzzer)

update the docs
update the get_clang script
start using -fsanitize=fuzzer by default
don't build libFuzzer from source (by default, and in the tutorial docs)
rebuild the tutorial docker files (once everything else is done, I'll do that)

Have runners execute on dedicated cores

We would like to minimize the impact of runner bookkeeping operations (copying corpus, rsync, etc.) on fuzzing times. One way to approach this is to limit fuzzing to a dedicated VM core and use the other core for bookkeeping operations.

Assigning to David for now, but it's probably more important for him to get an end-to-end system running before he leaves.

add a benchmark for libvorbis's CVE-2018-5146

xiph/vorbis@667ceb4 fixes a pwn2own-reported bug in vorbis, so it's interesting to have a benchmark for the previous revision (xiph/vorbis@c1c2831).

The fuzz target can be taken from https://github.com/google/oss-fuzz/blob/master/projects/vorbis/decode_fuzzer.cc (don't copy it, just git clone today's revision)

Maybe add one simple ogg file as a seed corpus, but don't add any large seed corpus (at least yet) -- the benchmark is interesting w/o the corpus.

@choller FYI

does providing LLVMFuzzerCustomMutator stop other mutations?

If I implement LLVMFuzzerCustomMutator will libfuzzer still perform all of the same standard mutations as before? Or does implementing this function cancel all the other mutations and it only runs the implementation given?

False positive of Use-after-free in benchmark pcre2-10.00

Hi there,

I try to use the benchmark pcre2-10.00 in fuzzer-test-suite to find the use-after-free bug.
When running libfuzzer for a while, it found a use-after-free bug. But when I run the POC file again. AddressSanitizer reports buffer-overflow rather than use-after-free.

So I guess it's actually a buffer-overflow because of Address Sanitizer's false positives(Red zone size is too small, the buffer overflow to the freed field). Their backtrace seems the same, but same POC leads to different ASAN report.

For example, ASAN report use-after-free (the red zone size is small):
artifact_prefix='./'; Test unit written to ./crash-94758a90604d8751863a24d13fda72e788d4b421

=================================================================
==192986==ERROR: AddressSanitizer: heap-use-after-free on address 0x61400069b0c6 at pc 0x0000005df924 bp 0x7ffe0f6aa710 sp 0x7ffe0f6aa708
READ of size 1 at 0x61400069b0c6 thread T0
     #0 0x5df923 in match /home/wencheng/FuzzingObject/fuzzer-test-suite/pcre2-10.00/build/BUILD/src/pcre2_match.c:1426:16
     #1 0x5d5082 in match /home/wencheng/FuzzingObject/fuzzer-test-suite/pcre2-10.00/build/BUILD/src/pcre2_match.c:5304:11
     #2 0x5c8923 in match /home/wencheng/FuzzingObject/fuzzer-test-suite/pcre2-10.00/build/BUILD/src/pcre2_match.c:1110:7
     #3 0x59e1dd in pcre2_match_8 /home/wencheng/FuzzingObject/fuzzer-test-suite/pcre2-10.00/build/BUILD/src/pcre2_match.c:6876:8
     #4 0x5f2c8f in regexec /home/wencheng/FuzzingObject/fuzzer-test-suite/pcre2-10.00/build/BUILD/src/pcre2posix.c:291:6
     #5 0x551771 in LLVMFuzzerTestOneInput /home/wencheng/FuzzingObject/fuzzer-test-suite/pcre2-10.00/build/../target.cc:17:5
    #6 0x42fbb5 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) /home/wencheng/Documents/llvm-6.0.1/projects/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:515
    #7 0x435021 in fuzzer::Fuzzer::RunOne(unsigned char const*, unsigned long, bool, fuzzer::InputInfo*, bool*) /home/wencheng/Documents/llvm-6.0.1/projects/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:440
    #8 0x435021 in fuzzer::Fuzzer::MutateAndTestOne() /home/wencheng/Documents/llvm-6.0.1/projects/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:649
    #9 0x437e8f in fuzzer::Fuzzer::Loop(std::vector<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, fuzzer::fuzzer_allocator<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > > const&) /home/wencheng/Documents/llvm-6.0.1/projects/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:775
   #10 0x429243 in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) /home/wencheng/Documents/llvm-6.0.1/projects/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:754
   #11 0x41d5f2 in main /home/wencheng/Documents/llvm-6.0.1/projects/compiler-rt/lib/fuzzer/FuzzerMain.cpp:20
   #12 0x7f9ae9ae282f in __libc_start_main /build/glibc-Cl5G7W/glibc-2.23/csu/../csu/libc-start.c:291
   #13 0x41d668 in _start (/home/wencheng/FuzzingObject/fuzzer-test-suite/pcre2-10.00/build/pcre2-10.00-fsanitize_fuzzer+0x41d668)

0x61400069b0c6 is located 134 bytes inside of 446-byte region [0x61400069b040,0x61400069b1fe)
freed by thread T0 here:
    #0 0x54dcb8 in operator delete[](void*) /home/wencheng/Documents/llvm-6.0.1/projects/compiler-rt/lib/asan/asan_new_delete.cc:152
    #1 0x435021 in fuzzer::Fuzzer::RunOne(unsigned char const*, unsigned long, bool, fuzzer::InputInfo*, bool*) /home/wencheng/Documents/llvm-6.0.1/projects/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:440
    #2 0x435021 in fuzzer::Fuzzer::MutateAndTestOne() /home/wencheng/Documents/llvm-6.0.1/projects/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:649
    #3 0x437e8f in fuzzer::Fuzzer::Loop(std::vector<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, fuzzer::fuzzer_allocator<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > > const&) /home/wencheng/Documents/llvm-6.0.1/projects/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:775
    #4 0x429243 in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) /home/wencheng/Documents/llvm-6.0.1/projects/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:754
    #5 0x41d5f2 in main /home/wencheng/Documents/llvm-6.0.1/projects/compiler-rt/lib/fuzzer/FuzzerMain.cpp:20
    #6 0x7f9ae9ae282f in __libc_start_main /build/glibc-Cl5G7W/glibc-2.23/csu/../csu/libc-start.c:291

previously allocated by thread T0 here:
    #0 0x54cf60 in operator new[](unsigned long) /home/wencheng/Documents/llvm-6.0.1/projects/compiler-rt/lib/asan/asan_new_delete.cc:95
    #1 0x42faf7 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) /home/wencheng/Documents/llvm-6.0.1/projects/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:506
    #2 0x435021 in fuzzer::Fuzzer::RunOne(unsigned char const*, unsigned long, bool, fuzzer::InputInfo*, bool*) /home/wencheng/Documents/llvm-6.0.1/projects/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:440
    #3 0x435021 in fuzzer::Fuzzer::MutateAndTestOne() /home/wencheng/Documents/llvm-6.0.1/projects/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:649
    #4 0x437e8f in fuzzer::Fuzzer::Loop(std::vector<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, fuzzer::fuzzer_allocator<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > > const&) /home/wencheng/Documents/llvm-6.0.1/projects/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:775
    #5 0x429243 in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) /home/wencheng/Documents/llvm-6.0.1/projects/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:754
    #6 0x41d5f2 in main /home/wencheng/Documents/llvm-6.0.1/projects/compiler-rt/lib/fuzzer/FuzzerMain.cpp:20
    #7 0x7f9ae9ae282f in __libc_start_main /build/glibc-Cl5G7W/glibc-2.23/csu/../csu/libc-start.c:291

SUMMARY: AddressSanitizer: heap-use-after-free /home/wencheng/FuzzingObject/fuzzer-test-suite/pcre2-10.00/build/BUILD/src/pcre2_match.c:1426:16 in match
Shadow bytes around the buggy address:
  0x0c28800cb5c0: fa fa fa fa fa fa fa fa fd fd fd fd fd fd fd fd
  0x0c28800cb5d0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x0c28800cb5e0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x0c28800cb5f0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x0c28800cb600: fa fa fa fa fa fa fa fa fd fd fd fd fd fd fd fd
=>0x0c28800cb610: fd fd fd fd fd fd fd fd[fd]fd fd fd fd fd fd fd
  0x0c28800cb620: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x0c28800cb630: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x0c28800cb640: fa fa fa fa fa fa fa fa fd fd fd fd fd fd fd fd
  0x0c28800cb650: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x0c28800cb660: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
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
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  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
==192986==ABORTING

ASAN report buffer-overflow (the red zone size is larger):
./pcre2-10.00-fsanitize_fuzzer ./crash-94758a90604d8751863a24d13fda72e788d4b421

=================================================================
==12987==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x61e000007f5a at pc 0x0000005df924 bp 0x7ffcea0902b0 sp 0x7ffcea0902a8
READ of size 1 at 0x61e000007f5a thread T0
    #0 0x5df923 in match /home/wencheng/FuzzingObject/fuzzer-test-suite/pcre2-10.00/build/BUILD/src/pcre2_match.c:1426:16
    #1 0x5d5082 in match /home/wencheng/FuzzingObject/fuzzer-test-suite/pcre2-10.00/build/BUILD/src/pcre2_match.c:5304:11
    #2 0x5c8923 in match /home/wencheng/FuzzingObject/fuzzer-test-suite/pcre2-10.00/build/BUILD/src/pcre2_match.c:1110:7
    #3 0x59e1dd in pcre2_match_8 /home/wencheng/FuzzingObject/fuzzer-test-suite/pcre2-10.00/build/BUILD/src/pcre2_match.c:6876:8
    #4 0x5f2c8f in regexec /home/wencheng/FuzzingObject/fuzzer-test-suite/pcre2-10.00/build/BUILD/src/pcre2posix.c:291:6
    #5 0x551771 in LLVMFuzzerTestOneInput /home/wencheng/FuzzingObject/fuzzer-test-suite/pcre2-10.00/build/../target.cc:17:5
   #6 0x42fbb5 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) /home/wencheng/Documents/llvm-6.0.1/projects/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:515
   #7 0x41f3da in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) /home/wencheng/Documents/llvm-6.0.1/projects/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:280
   #8 0x4291e3 in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) /home/wencheng/Documents/llvm-6.0.1/projects/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:703
   #9 0x41d5f2 in main /home/wencheng/Documents/llvm-6.0.1/projects/compiler-rt/lib/fuzzer/FuzzerMain.cpp:20
  #10 0x7fdc97fed82f in __libc_start_main /build/glibc-Cl5G7W/glibc-2.23/csu/../csu/libc-start.c:291
  #11 0x41d668 in _start (/home/wencheng/FuzzingObject/fuzzer-test-suite/pcre2-10.00/build/pcre2-10.00-fsanitize_fuzzer+0x41d668)

Address 0x61e000007f5a is a wild pointer.
SUMMARY: AddressSanitizer: heap-buffer-overflow /home/wencheng/FuzzingObject/fuzzer-test-suite/pcre2-10.00/build/BUILD/src/pcre2_match.c:1426:16 in match
Shadow bytes around the buggy address:
  0x0c3c7fff8f90: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c3c7fff8fa0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c3c7fff8fb0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c3c7fff8fc0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c3c7fff8fd0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
=>0x0c3c7fff8fe0: fa fa fa fa fa fa fa fa fa fa fa[fa]fa fa fa fa
  0x0c3c7fff8ff0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c3c7fff9000: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c3c7fff9010: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c3c7fff9020: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c3c7fff9030: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
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
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  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
==12987==ABORTING

I also try to use AFL to test pcre2-10.00. Within 48 hours, AFL did not find use-after-free. But the README.md said that fuzzer can find use-after-free in less than a minute. If you are sure that this is not Address Sanitizer's false alarm, can you provide use-after-free POC files?

I am using this benchmark to do the experiment for finding the use-after-free bug. And I can't find this use-after-free using AFL and libfuzzer. I hope you can help improving this benchmark.

Thank you very much.

libFuzzer no longer behaves as expected on re2 benchmark

The line below is never output:

INFO: found line matching 're2/dfa.cc:474'

Also, my last run encountered the OOM below before it ever found the heap buffer overflow.

==170102== ERROR: libFuzzer: out-of-memory (used: 2049Mb; limit: 2048Mb)
   To change the out-of-memory limit use -rss_limit_mb=<N>

Live Heap Allocations: 26732490 bytes in 16269 chunks; quarantined: 254950065 bytes in 10775 chunks; 7819808 other chunks; total chunks: 7846852; showing top 95% (at most 8 unique contexts)
16777432 byte(s) (62%) in 1 allocation(s)
    #0 0x4eb062 in operator new(unsigned long) /usr/local/google/home/mascasa/code/llvm/llvm-project/compiler-rt/lib/asan/asan_new_delete.cc:92:3
    #1 0x59071d in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) /usr/local/google/home/mascasa/code/fts/re2/../Fuzzer/FuzzerDriver.cpp:622:18
    #2 0x58bd90 in main /usr/local/google/home/mascasa/code/fts/re2/../Fuzzer/FuzzerMain.cpp:20:10
    #3 0x7f1954107f44 in __libc_start_main /build/eglibc-SvCtMH/eglibc-2.19/csu/libc-start.c:287