leak detection with afl-fuzz?

552 views
Skip to first unread message

Dominique Pellé

unread,
Aug 16, 2015, 9:45:20 AM8/16/15
to afl-...@googlegroups.com
Hi

Has anybody been able to use lsan (leak sanitizer) along with afl-fuzz?

Unlike asan, lsan does not abort on errors. So afl-fuzz ignores it.
I see at https://code.google.com/p/address-sanitizer/wiki/LeakSanitizer
that the LSAN_OPTIONS environment variable can be used to change
the exit code, but I don't see a way to make lsan abort.

Besides lsan, I also see drmemory (http://drmemory.org/) which can
detect leaks + similar memory errors detected by valgrind, but faster
than valgrind. Has anybody been using drmemory with afl-fuzz?
I don't see an option to make it abort on error either.

Regards
Dominique

Jacek Wielemborek

unread,
Aug 16, 2015, 11:29:57 AM8/16/15
to afl-...@googlegroups.com
W dniu 16.08.2015 o 15:44, Dominique Pellé pisze:
Hi,

I hadn't looked into this much, but if I found the right project's code,
perhaps it would be enough to add abort(); instead of exit() here and
recompile?

https://github.com/autc04/Retro68/blob/0bd7c6dcdfdf552236da8187c078732078976955/gcc/libsanitizer/lsan/lsan_common.cc#L409

Generally, I would try to trace this environment variable in the code,
find the relevant exit() and replace it with abort().

Cheers,
d33tah

signature.asc

Michal Zalewski

unread,
Aug 16, 2015, 5:01:37 PM8/16/15
to afl-users
A quick hack would be to find this code in afl-fuzz.c:

if (memmem(f_data, f_len, "libasan.so", 10) ||
memmem(f_data, f_len, "__msan_init", 11)) uses_asan = 1;

...then, find some LSAN-specific string to check for in LSANified
binaries, and add that to the conditional, and then find this:

setenv("MSAN_OPTIONS", "exit_code=" STRINGIFY(MSAN_ERROR) ":"
"msan_track_origins=0", 0);

and append:

setenv("LSAN_OPTIONS", "exitcode=" STRINGIFY(MSAN_ERROR), 0);

...the last part happens in two locations in the codebase, so you'd
need to find both.

I'm guessing this should work. It would be really nice if all the
sanitizers followed at least somewhat similar conventions, though :-(

/mz

Konstantin Serebryany

unread,
Aug 17, 2015, 10:38:51 PM8/17/15
to afl-...@googlegroups.com
Oh my, indeed: 
lib/asan/asan_flags.inc:ASAN_FLAG(int, exitcode, ASAN_DEFAULT_FAILURE_EXITCODE,
lib/tsan/rtl/tsan_flags.inc:TSAN_FLAG(int, exitcode, 66, "Override exit status if something was reported.")
lib/msan/msan_flags.inc:MSAN_FLAG(int, exit_code, 77, "")
lib/lsan/lsan_flags.inc:LSAN_FLAG(int, exitcode, 23,

We'll need to make exitcode and exit_code aliases of each other in all of the sanitizers. 

BTW, we (the *san authors) respond quicker in our mailing lists :) 

--kcc 

 

/mz

--
You received this message because you are subscribed to the Google Groups "afl-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to afl-users+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Michal Zalewski

unread,
Aug 17, 2015, 10:42:49 PM8/17/15
to afl-users
> We'll need to make exitcode and exit_code aliases of each other in all of
> the sanitizers.

Would be also cool to have them all support common semantics for
aborting on error (I think this is done differently in ASAN, in MSAN,
in UBSAN, and not available at all in LSAN).

Cheers,
/mz

Konstantin Serebryany

unread,
Aug 17, 2015, 10:45:52 PM8/17/15
to afl-...@googlegroups.com
That's possible too, although may require more work. 

 

Cheers,
Reply all
Reply to author
Forward
0 new messages