Segmentation fault when running afl-fuzz_kscheduler about k-scheduler HOT 7 CLOSED

I am guessing this issue is caused by large number of instrumented edges on some large programs. Default AFL only supports 65536 number of edges. If the total number of edges is greater than 65536, you need to use afl in https://github.com/Dongdongshe/K-Scheduler/tree/main/afl_integration/afl-2.52b_kscheduler_large_bitmap, where the bitmap size is 131072.

To find the total number of edges in a program, do "wc -l katz_cent". If you see the number is greater than 65536, use the afl-fuzz in https://github.com/Dongdongshe/K-Scheduler/tree/main/afl_integration/afl-2.52b_kscheduler_large_bitmap.

from k-scheduler.

Thanks for your kind reply, your guessing is correct!

Both faust and objdump have more than 65536 edges. The
afl-2.52b_kscheduler_large_bitmap works on objdump.

However, when executing faust, the fuzzer aborted.

GDB

➜  git:(main) ✗ gdb ./afl-fuzz_kscheduler_large_bitmap                                                                                           
...
(gdb) r -m none -d  -i fuzz_in -o fuzz_out -- ./faust -lang ocpp -e -lcc -exp10 -lb -rb -mem -sd @@
Starting program: /home/xxx//kscheduler/kscheduler_faust/base_d/afl-fuzz_kscheduler_large_bitmap -m none -d  -i fuzz_in -o fuzz_out -- ./faust -lang ocpp -e -lcc -exp10 -lb -rb -mem -sd @@
afl-fuzz 2.52b by <[email protected]>
...
[+] All right - fork server is up.
*** stack smashing detected ***: terminated

Program received signal SIGABRT, Aborted.
__GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
50      ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.

(gdb) backtrace
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1  0x00007ffff7c97859 in __GI_abort () at abort.c:79
#2  0x00007ffff7d0226e in __libc_message (action=action@entry=do_abort, fmt=fmt@entry=0x7ffff7e2c08f "*** %s ***: terminated\n")
    at ../sysdeps/posix/libc_fatal.c:155
#3  0x00007ffff7da4aba in __GI___fortify_fail (msg=msg@entry=0x7ffff7e2c077 "stack smashing detected") at fortify_fail.c:26
#4  0x00007ffff7da4a86 in __stack_chk_fail () at stack_chk_fail.c:24
#5  0x000055555555bce7 in run_target (argv=<optimized out>, timeout=<optimized out>) at afl-fuzz.c:2743
#6  0x00005555555652c7 in calibrate_case_dry_run (handicap=0, from_queue=1 '\001', use_mem=<optimized out>, q=0x555556d983a8, argv=<optimized out>)
    at afl-fuzz.c:3069
#7  perform_dry_run (argv=0x7fffffffdef0) at afl-fuzz.c:3234
#8  0x0000555555558b5d in main (argc=20, argv=0x7fffffffdea8) at afl-fuzz.c:8577

POC

The sizes of the binary (32.4M) and related files are too big for GitHub, I could upload them to a cloud if necessary.

from k-scheduler.

From the stack trace, I cannot figure out the crash reason. Could you upload the binary and related files to Google cloud and send the link to my emial?

from k-scheduler.

From the stack trace, I cannot figure out the crash reason. Could you upload the binary and related files to Google cloud and send the link to my emial?

Thanks a lot. I have upload them to google drive and send an email to you (dongdong at cs.columbia.edu)

from k-scheduler.

I am guessing this issue is caused by large number of instrumented edges on some large programs. Default AFL only supports 65536 number of edges. If the total number of edges is greater than 65536, you need to use afl in https://github.com/Dongdongshe/K-Scheduler/tree/main/afl_integration/afl-2.52b_kscheduler_large_bitmap, where the bitmap size is 131072.

To find the total number of edges in a program, do "wc -l katz_cent". If you see the number is greater than 65536, use the afl-fuzz in https://github.com/Dongdongshe/K-Scheduler/tree/main/afl_integration/afl-2.52b_kscheduler_large_bitmap.

I checked the edge number of the binary faust, and found that it is 133758. So it is also out of range for the afl-2.52b_kscheduler_large_bitmap (131072). I also set up another binary magick in ImageMagick, and it also failed as it has 202569 instrumented edges.

Should I avoid testing the binaries with large-sized edges? It also took a lot of time in graph generation (several hours).

from k-scheduler.

Theoretically, K-scheduler can support arbitrarily large program. The limit of bitmap size is an inherent issue of vanilla AFL, not scheduling algorithm. Vanilla AFL would use random edge ID assignment and place 133758 or 202569 unique edges into 65536 bitmap slots, leading to a serious edge collision issue.

In practice, I would suggest try to use some wrappers to test different APIs in some large project like faust and ImageMagick like Google Fuzzbench, rather than a single large binary. The wrapper is more flexible and can test different APIs.

The overhead of graph generation on a few large programs is caused by inefficient text processing of python. This overhead only occurs at the initial graph analysis before fuzzing campaign and would not cause any runtime overhead during fuzzing.

from k-scheduler.

Thanks a lot for your kind suggestion!
I have extended KScheduler to support 131072*2 edges by modifying the setting in config.h and it looks good to me.
I agree with your points that a wrapper supporting API is better for such a large binary, so I will try FuzzBench for further evaluation :)

from k-scheduler.