Bug 7862

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.