Segmentation Fault 2018-01-30

[Ryan Whitworth]

Hello, I was using American Fuzzy Lop (afl-fuzz) to fuzz input to the bzzasm program on Linux. Is fixing the crashes from these input files something you're interested in? An example input file causing a crash is: r|r# (yes, that's the entire program)

The file can be executed as ./bzzasm id_filename /tmp/1 /tmp/2 to cause a seg fault. I have been able to reproduce with clang and gcc.

Valgrind output looks as such:

==28975== Memcheck, a memory error detector
==28975== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==28975== Using Valgrind-3.12.0.SVN and LibVEX; rerun with -h for copyright info
==28975== Command: ./bzzasm ./test /tmp/1 /tmp/2
==28975==
==28975== Invalid read of size 1
==28975==    at 0x55A3CC5: ____strtol_l_internal (strtol_l.c:293)
==28975==    by 0x4E3A854: buzz_asm (in /root/buzz-2/src/buzz/libbuzzdbg.so)
==28975==    by 0x400ACA: main (in /root/buzz-2/src/buzz/bzzasm)
==28975==  Address 0x0 is not stack'd, malloc'd or (recently) free'd
==28975==
==28975==
==28975== Process terminating with default action of signal 11 (SIGSEGV)
==28975==  Access not within mapped region at address 0x0
==28975==    at 0x55A3CC5: ____strtol_l_internal (strtol_l.c:293)
==28975==    by 0x4E3A854: buzz_asm (in /root/buzz-2/src/buzz/libbuzzdbg.so)
==28975==    by 0x400ACA: main (in /root/buzz-2/src/buzz/bzzasm)
==28975==  If you believe this happened as a result of a stack
==28975==  overflow in your program's main thread (unlikely but
==28975==  possible), you can try to increase the size of the
==28975==  main thread stack using the --main-stacksize= flag.
==28975==  The main thread stack size used in this run was 8388608.
==28975==
==28975== HEAP SUMMARY:
==28975==     in use at exit: 4,452 bytes in 15 blocks
==28975==   total heap usage: 16 allocs, 1 frees, 8,548 bytes allocated
==28975==
==28975== LEAK SUMMARY:
==28975==    definitely lost: 0 bytes in 0 blocks
==28975==    indirectly lost: 0 bytes in 0 blocks
==28975==      possibly lost: 0 bytes in 0 blocks
==28975==    still reachable: 4,452 bytes in 15 blocks
==28975==         suppressed: 0 bytes in 0 blocks
==28975== Rerun with --leak-check=full to see details of leaked memory
==28975==
==28975== For counts of detected and suppressed errors, rerun with: -v
==28975== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
Segmentation fault

Let me know if I can provide any more information to help narrow down this issue.

[Carlo Pinciroli]

Hello! Yes, I'd be very interested in this kind of testing. Buzz is very much an experimental language, at the moment, and automated testing is very useful. I'd be happy to include it in make test, if that makes sense.