I'm fuzzing busybox with american fuzzy lop (http://lcamtuf.coredump.cx/afl) and I found a test case which causes sh to segfault. Compilation steps on Debian 7 x64: 1) edited the Makefile to point to afl-gcc and afl-gxx instead of the system defaults for binary instrumention. 2) make menuconfig (defaults only, nothing extra selected or toggled) 3) make BusyBox v1.24.0.git (2015-02-02 16:46:08 CST) GDB output: Program received signal SIGSEGV, Segmentation fault. [Switching to process 45939] [----------------------------------registers-----------------------------------] RAX: 0x1 RBX: 0xb17310 --> 0xb17340 --> 0x0 RCX: 0x0 RDX: 0x0 RSI: 0x7fffffffd7f0 --> 0x0 RDI: 0xd ('\r') RBP: 0x0 RSP: 0x7fffffffd9f0 --> 0x0 RIP: 0x51c424 (mov rsi,QWORD PTR [rcx+0x18]) R8 : 0x7fffffffd8a0 --> 0x1 R9 : 0xb169 R10: 0x8 R11: 0x202 R12: 0xb17550 --> 0x100000000 R13: 0xb17010 --> 0x10000b169 R14: 0x0 R15: 0x8 EFLAGS: 0x10202 (carry parity adjust zero sign trap INTERRUPT direction overflow) [-------------------------------------code-------------------------------------] 0x51c414: mov r15d,DWORD PTR [rsp+0x24] 0x51c419: mov rbx,QWORD PTR [rip+0x5fa6e8] # 0xb16b08 0x51c420: mov DWORD PTR [rbx+0x28],r15d => 0x51c424: mov rsi,QWORD PTR [rcx+0x18] 0x51c428: mov rdi,QWORD PTR [rcx+0x10] 0x51c42c: call 0x7c2448 0x51c431: mov rsi,QWORD PTR [rbx+0x10] 0x51c435: mov rdx,QWORD PTR [rip+0x5f4284] # 0xb106c0 [------------------------------------stack-------------------------------------] 0000| 0x7fffffffd9f0 --> 0x0 0008| 0x7fffffffd9f8 --> 0x7ffff7ffaf18 --> 0x403c8c ("GLIBC_2.2.5") 0016| 0x7fffffffda00 --> 0xffffffff00000001 0024| 0x7fffffffda08 --> 0x300000000 0032| 0x7fffffffda10 --> 0x800000007 0040| 0x7fffffffda18 --> 0x7ffff7ffe1c8 --> 0x0 0048| 0x7fffffffda20 --> 0xb17378 --> 0x0 0056| 0x7fffffffda28 --> 0x0 [------------------------------------------------------------------------------] Legend: code, data, rodata, value Stopped reason: SIGSEGV 0x000000000051c424 in ?? () gdb-peda$ bt #0 0x000000000051c424 in ?? () #1 0x0000000000000000 in ?? () gdb-peda$ i r rax 0x1 0x1 rbx 0xb17310 0xb17310 rcx 0x0 0x0 rdx 0x0 0x0 rsi 0x7fffffffd7f0 0x7fffffffd7f0 rdi 0xd 0xd rbp 0x0 0x0 rsp 0x7fffffffd9f0 0x7fffffffd9f0 r8 0x7fffffffd8a0 0x7fffffffd8a0 r9 0xb169 0xb169 r10 0x8 0x8 r11 0x202 0x202 r12 0xb17550 0xb17550 r13 0xb17010 0xb17010 r14 0x0 0x0 r15 0x8 0x8 rip 0x51c424 0x51c424 eflags 0x10202 [ IF RF ] cs 0x33 0x33 ss 0x2b 0x2b ds 0x0 0x0 es 0x0 0x0 fs 0x0 0x0 gs 0x0 0x0 Valgrind output: ==14202== Invalid read of size 8 ==14202== at 0x51C424: ??? (in /home/geeknik/busybox/busybox) ==14202== Address 0x18 is not stack'd, malloc'd or (recently) free'd ==14202== ==14202== ==14202== Process terminating with default action of signal 11 (SIGSEGV): dumping core ==14202== Access not within mapped region at address 0x18 ==14202== at 0x51C424: ??? (in /home/geeknik/busybox/busybox) ==14202== If you believe this happened as a result of a stack ==14202== overflow in your program's main thread (unlikely but ==14202== possible), you can try to increase the size of the ==14202== main thread stack using the --main-stacksize= flag. ==14202== The main thread stack size used in this run was 8388608. ==13702== Invalid read of size 1 ==13702== at 0x7C3503: ??? (in /home/geeknik/busybox/busybox) ==13702== by 0x543D457: ??? ==13702== by 0x543D457: ??? ==13702== by 0x543D457: ??? ==13702== Address 0x13 is not stack'd, malloc'd or (recently) free'd ==13702== ==13702== ==13702== Process terminating with default action of signal 11 (SIGSEGV): dumping core ==13702== Access not within mapped region at address 0x13 ==13702== at 0x7C3503: ??? (in /home/geeknik/busybox/busybox) ==13702== by 0x543D457: ??? ==13702== by 0x543D457: ??? ==13702== by 0x543D457: ??? ==13702== If you believe this happened as a result of a stack ==13702== overflow in your program's main thread (unlikely but ==13702== possible), you can try to increase the size of the ==13702== main thread stack using the --main-stacksize= flag. ==13702== The main thread stack size used in this run was 8388608. Segmentation fault command line: ./busybox sh test-case Hexdump: 0000000 3c3c c011 202f 203b 6874 6e65 5b3c 2f3c 0000010 007f 0000011 Test case attached.
Created attachment 5846 [details] test case
The gist of it, this was not handler corrently: <<EOF; then <W Fixed in git, thanks!