Segmentation Faults 2017-05-16

[rwhitworth]

Hello,
I was using American Fuzzy Lop (afl-fuzz) to fuzz input to the 8cc program on Linux. Is fixing the crashes from these input files something you're interested in? The input files can be found here: https://github.com/rwhitworth/8cc-fuzz.

The files can be executed as ./8cc -c id_filename to cause seg faults.

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

[rwhitworth]

Example valgrind output of a few items:

==1308769== Memcheck, a memory error detector
==1308769== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==1308769== Using Valgrind-3.10.0 and LibVEX; rerun with -h for copyright info
==1308769== Command: /root/8cc/8cc -c id:000000,sig:11,src:000000,op:flip1,pos:12
==1308769==
==1308769== Invalid read of size 8
==1308769==    at 0x44AA89: read_unary_deref (parse.c:1078)
==1308769==    by 0x44AA89: read_unary_expr (parse.c:1117)
==1308769==    by 0x44CEAC: read_cast_expr (parse.c:1152)
==1308769==    by 0x44D1D2: read_multiplicative_expr (parse.c:1156)
==1308769==    by 0x44D8A2: read_additive_expr (parse.c:1166)
==1308769==    by 0x44DDDD: read_shift_expr (parse.c:1175)
==1308769==    by 0x44E452: read_relational_expr (parse.c:1193)
==1308769==    by 0x44E452: read_equality_expr (parse.c:1205)
==1308769==    by 0x44EE62: read_bitand_expr (parse.c:1219)
==1308769==    by 0x44F1A2: read_bitxor_expr (parse.c:1226)
==1308769==    by 0x44F4E2: read_bitor_expr (parse.c:1233)
==1308769==    by 0x44F829: read_logand_expr (parse.c:1240)
==1308769==    by 0x44FBC9: read_logor_expr (parse.c:1247)
==1308769==    by 0x44FF6E: read_assignment_expr (parse.c:1277)
==1308769==  Address 0x8 is not stack'd, malloc'd or (recently) free'd
==1308769==
==1308769==
==1308769== Process terminating with default action of signal 11 (SIGSEGV)
==1308769==  Access not within mapped region at address 0x8
==1308769==    at 0x44AA89: read_unary_deref (parse.c:1078)
==1308769==    by 0x44AA89: read_unary_expr (parse.c:1117)
==1308769==    by 0x44CEAC: read_cast_expr (parse.c:1152)
==1308769==    by 0x44D1D2: read_multiplicative_expr (parse.c:1156)
==1308769==    by 0x44D8A2: read_additive_expr (parse.c:1166)
==1308769==    by 0x44DDDD: read_shift_expr (parse.c:1175)
==1308769==    by 0x44E452: read_relational_expr (parse.c:1193)
==1308769==    by 0x44E452: read_equality_expr (parse.c:1205)
==1308769==    by 0x44EE62: read_bitand_expr (parse.c:1219)
==1308769==    by 0x44F1A2: read_bitxor_expr (parse.c:1226)
==1308769==    by 0x44F4E2: read_bitor_expr (parse.c:1233)
==1308769==    by 0x44F829: read_logand_expr (parse.c:1240)
==1308769==    by 0x44FBC9: read_logor_expr (parse.c:1247)
==1308769==    by 0x44FF6E: read_assignment_expr (parse.c:1277)
==1308769==  If you believe this happened as a result of a stack
==1308769==  overflow in your program's main thread (unlikely but
==1308769==  possible), you can try to increase the size of the
==1308769==  main thread stack using the --main-stacksize= flag.
==1308769==  The main thread stack size used in this run was 8388608.
==1308769==
==1308769== HEAP SUMMARY:
==1308769==     in use at exit: 35,736 bytes in 779 blocks
==1308769==   total heap usage: 788 allocs, 9 frees, 39,242 bytes allocated
==1308769==
==1308769== LEAK SUMMARY:
==1308769==    definitely lost: 15,496 bytes in 373 blocks
==1308769==    indirectly lost: 1,472 bytes in 68 blocks
==1308769==      possibly lost: 0 bytes in 0 blocks
==1308769==    still reachable: 18,768 bytes in 338 blocks
==1308769==         suppressed: 0 bytes in 0 blocks
==1308769== Rerun with --leak-check=full to see details of leaked memory
==1308769==
==1308769== For counts of detected and suppressed errors, rerun with: -v
==1308769== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)

==1389328== Memcheck, a memory error detector
==1389328== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==1389328== Using Valgrind-3.10.0 and LibVEX; rerun with -h for copyright info
==1389328== Command: /root/8cc/8cc -c id:000001,sig:11,src:000000,op:flip1,pos:23
==1389328==
==1389328== Invalid read of size 8
==1389328==    at 0x44672C: binop (parse.c:577)
==1389328==    by 0x44DA29: read_additive_expr (parse.c:1168)
==1389328==    by 0x44DDDD: read_shift_expr (parse.c:1175)
==1389328==    by 0x44E452: read_relational_expr (parse.c:1193)
==1389328==    by 0x44E452: read_equality_expr (parse.c:1205)
==1389328==    by 0x44EE62: read_bitand_expr (parse.c:1219)
==1389328==    by 0x44F1A2: read_bitxor_expr (parse.c:1226)
==1389328==    by 0x44F4E2: read_bitor_expr (parse.c:1233)
==1389328==    by 0x44F829: read_logand_expr (parse.c:1240)
==1389328==    by 0x44FBC9: read_logor_expr (parse.c:1247)
==1389328==    by 0x44FF6E: read_assignment_expr (parse.c:1277)
==1389328==    by 0x4508E9: read_comma_expr (parse.c:1298)
==1389328==    by 0x4614E4: read_expr_opt (parse.c:1315)
==1389328==    by 0x4614E4: read_return_stmt (parse.c:2605)
==1389328==    by 0x4614E4: read_stmt (parse.c:2652)
==1389328==  Address 0x8 is not stack'd, malloc'd or (recently) free'd
==1389328==
==1389328==
==1389328== Process terminating with default action of signal 11 (SIGSEGV)
==1389328==  Access not within mapped region at address 0x8
==1389328==    at 0x44672C: binop (parse.c:577)
==1389328==    by 0x44DA29: read_additive_expr (parse.c:1168)
==1389328==    by 0x44DDDD: read_shift_expr (parse.c:1175)
==1389328==    by 0x44E452: read_relational_expr (parse.c:1193)
==1389328==    by 0x44E452: read_equality_expr (parse.c:1205)
==1389328==    by 0x44EE62: read_bitand_expr (parse.c:1219)
==1389328==    by 0x44F1A2: read_bitxor_expr (parse.c:1226)
==1389328==    by 0x44F4E2: read_bitor_expr (parse.c:1233)
==1389328==    by 0x44F829: read_logand_expr (parse.c:1240)
==1389328==    by 0x44FBC9: read_logor_expr (parse.c:1247)
==1389328==    by 0x44FF6E: read_assignment_expr (parse.c:1277)
==1389328==    by 0x4508E9: read_comma_expr (parse.c:1298)
==1389328==    by 0x4614E4: read_expr_opt (parse.c:1315)
==1389328==    by 0x4614E4: read_return_stmt (parse.c:2605)
==1389328==    by 0x4614E4: read_stmt (parse.c:2652)
==1389328==  If you believe this happened as a result of a stack
==1389328==  overflow in your program's main thread (unlikely but
==1389328==  possible), you can try to increase the size of the
==1389328==  main thread stack using the --main-stacksize= flag.
==1389328==  The main thread stack size used in this run was 8388608.
==1389328==
==1389328== HEAP SUMMARY:
==1389328==     in use at exit: 35,968 bytes in 784 blocks
==1389328==   total heap usage: 793 allocs, 9 frees, 39,474 bytes allocated
==1389328==
==1389328== LEAK SUMMARY:
==1389328==    definitely lost: 15,640 bytes in 376 blocks
==1389328==    indirectly lost: 1,480 bytes in 69 blocks
==1389328==      possibly lost: 0 bytes in 0 blocks
==1389328==    still reachable: 18,848 bytes in 339 blocks
==1389328==         suppressed: 0 bytes in 0 blocks
==1389328== Rerun with --leak-check=full to see details of leaked memory
==1389328==
==1389328== For counts of detected and suppressed errors, rerun with: -v
==1389328== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)

==1419017== Memcheck, a memory error detector
==1419017== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==1419017== Using Valgrind-3.10.0 and LibVEX; rerun with -h for copyright info
==1419017== Command: /root/8cc/8cc -c id:000003,sig:11,src:000000,op:flip2,pos:13
==1419017==
==1419017== Invalid read of size 8
==1419017==    at 0x4508F5: read_comma_expr (parse.c:1301)
==1419017==    by 0x461254: read_expr_opt (parse.c:1315)
==1419017==    by 0x461254: read_stmt (parse.c:2664)
==1419017==    by 0x46510C: read_decl_or_stmt (parse.c:2692)
==1419017==    by 0x465717: read_compound_stmt (parse.c:2676)
==1419017==    by 0x4662F1: read_func_body (parse.c:2263)
==1419017==    by 0x4662F1: read_funcdef (parse.c:2351)
==1419017==    by 0x4662F1: read_toplevels (parse.c:2708)
==1419017==    by 0x402940: main (main.c:182)
==1419017==  Address 0x8 is not stack'd, malloc'd or (recently) free'd
==1419017==
==1419017==
==1419017== Process terminating with default action of signal 11 (SIGSEGV)
==1419017==  Access not within mapped region at address 0x8
==1419017==    at 0x4508F5: read_comma_expr (parse.c:1301)
==1419017==    by 0x461254: read_expr_opt (parse.c:1315)
==1419017==    by 0x461254: read_stmt (parse.c:2664)
==1419017==    by 0x46510C: read_decl_or_stmt (parse.c:2692)
==1419017==    by 0x465717: read_compound_stmt (parse.c:2676)
==1419017==    by 0x4662F1: read_func_body (parse.c:2263)
==1419017==    by 0x4662F1: read_funcdef (parse.c:2351)
==1419017==    by 0x4662F1: read_toplevels (parse.c:2708)
==1419017==    by 0x402940: main (main.c:182)
==1419017==  If you believe this happened as a result of a stack
==1419017==  overflow in your program's main thread (unlikely but
==1419017==  possible), you can try to increase the size of the
==1419017==  main thread stack using the --main-stacksize= flag.
==1419017==  The main thread stack size used in this run was 8388608.
==1419017==
==1419017== HEAP SUMMARY:
==1419017==     in use at exit: 35,736 bytes in 779 blocks
==1419017==   total heap usage: 788 allocs, 9 frees, 39,242 bytes allocated
==1419017==
==1419017== LEAK SUMMARY:
==1419017==    definitely lost: 15,496 bytes in 373 blocks
==1419017==    indirectly lost: 1,472 bytes in 68 blocks
==1419017==      possibly lost: 0 bytes in 0 blocks
==1419017==    still reachable: 18,768 bytes in 338 blocks
==1419017==         suppressed: 0 bytes in 0 blocks
==1419017== Rerun with --leak-check=full to see details of leaked memory
==1419017==
==1419017== For counts of detected and suppressed errors, rerun with: -v
==1419017== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)

[rofl0r]

in case you feel bored: sabotage-linux/gettext-tiny#11 ... i still dont have gcc with asan working on musl libc, and without asan fuzzing doesnt work too well.