Stability percentage dropping suddenly

Skip to first unread message

Alan Goodman

Aug 15, 2021, 11:11:58 AM8/15/21
to afl-users

I've been completing targeted fuzzing of some content parsing libraries after investigating existing fuzzing efforts and identifying some corner cases which I believe have not been covered.

I am configuring my target build as follows: CC=/usr/bin/afl-clang-fast CXX=/usr/bin/afl-clang-fast++ ./configure --disable-shared CFLAGS="-fsanitize=address -ggdb" CXXFLAGS="-fsanitize=address -ggdb" LDFLAGS="-fsanitize=address" followed by the usual make -j10

I am then running my fuzz session along the lines of: AFL_PRELOAD=/usr/lib/afl/ afl-fuzz -i - -o pathtoout -m none -M fuzzer01 -- ./path/to/bin input:@@ output and then the same but with -S and unique name for subsequent runs.  I am running 10-100 simultaneous -S instances and one -M process on some pretty serious hardware.

I am tuning timeout value manually and have a script to clean up dangling temp files as the binary is quite bent on crashing my system by consuming almost infinite ram / disk space on some occasions.

After a number of weeks (usually 2-4) I am finding the stability metric plummet to 40-60% however I am not seeing any crashes,

I am hoping to find memory type issues - buffer overruns, overreads etc.  My gut feeling is I am probably running into interesting things but somehow doing something wrong which is leading me to not detect the issues correctly.

if anyone has any useful input this would be appreciated.


Alan Goodman

Aug 17, 2021, 6:55:59 PM8/17/21
to afl-users

To answer my own question, it seems that my subject executable unexpectedly multi threaded some specific test cases as they contained multiple valid inputs.  This appears to upset the stability indicator although it does not appear to upset any other functionality.  Running the subject executable limited to 1 thread appears to resolve the issue and results in much more predictable load.
Reply all
Reply to author
0 new messages