[Bug 7856] New: null pointer dereference in ash

Mon Feb 2 23:56:33 UTC 2015

https://bugs.busybox.net/show_bug.cgi?id=7856

           Summary: null pointer dereference in ash
           Product: Busybox
           Version: unspecified
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: critical
          Priority: P5
         Component: Other
        AssignedTo: unassigned at busybox.net
        ReportedBy: brian.carpenter at gmail.com
                CC: busybox-cvs at busybox.net
   Estimated Hours: 0.0

Created attachment 5840
  --> https://bugs.busybox.net/attachment.cgi?id=5840
Testcase that crashes busybox ash

I'm fuzzing busybox with american fuzzy lop (http://lcamtuf.coredump.cx/afl)
and I found a test case which causes ash to segfault, most likely because of a
null ptr deref.

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 49119]
id:000000,sig:11,src:000258,op:havoc,rep:16: line 1: ++: not found
[----------------------------------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 : 0xbd87
R10: 0x8
R11: 0x202
R12: 0xb17550 --> 0x100000000
R13: 0xb17010 --> 0x10000bd87
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 --> 0x7b4755 (add    rsp,0x8)
0016| 0x7fffffffda00 --> 0xffffffff007b3422
0024| 0x7fffffffda08 --> 0x300000000
0032| 0x7fffffffda10 --> 0x800000007
0040| 0x7fffffffda18 --> 0xb17400 --> 0x2b2b ('++')
0048| 0x7fffffffda20 --> 0x4f9bb2 (mov    rdx,QWORD PTR [rsp])
0056| 0x7fffffffda28 --> 0x0
[------------------------------------------------------------------------------]
Legend: code, data, rodata, value
Stopped reason: SIGSEGV
0x000000000051c424 in ?? ()
gdb-peda$ bt
#0  0x000000000051c424 in ?? ()
#1  0x0000000000000000 in ?? ()

Valgrind output:
==5301== Invalid read of size 8
==5301==    at 0x51C424: ??? (in /home/geeknik/busybox/busybox)
==5301==    by 0x543D3B7: ???
==5301==    by 0x7B4754: ??? (in /home/geeknik/busybox/busybox)
==5301==    by 0xFFFFFFFF007B3421: ???
==5301==    by 0x2FFFFFFFF: ???
==5301==    by 0x400000002: ???
==5301==    by 0x543D46F: ???
==5301==    by 0x4F9BB1: ??? (in /home/geeknik/busybox/busybox)
==5301==  Address 0x18 is not stack'd, malloc'd or (recently) free'd
==5301== 
==5301== 
==5301== Process terminating with default action of signal 11 (SIGSEGV):
dumping core
==5301==  Access not within mapped region at address 0x18
==5301==    at 0x51C424: ??? (in /home/geeknik/busybox/busybox)
==5301==    by 0x543D3B7: ???
==5301==    by 0x7B4754: ??? (in /home/geeknik/busybox/busybox)
==5301==    by 0xFFFFFFFF007B3421: ???
==5301==    by 0x2FFFFFFFF: ???
==5301==    by 0x400000002: ???
==5301==    by 0x543D46F: ???
==5301==    by 0x4F9BB1: ??? (in /home/geeknik/busybox/busybox)
==5301==  If you believe this happened as a result of a stack
==5301==  overflow in your program's main thread (unlikely but
==5301==  possible), you can try to increase the size of the
==5301==  main thread stack using the --main-stacksize= flag.
==5301==  The main thread stack size used in this run was 8388608.
id:000000,sig:11,src:000258,op:havoc,rep:16: line 1: ++: not found
==2822== Invalid read of size 1
==2822==    at 0x7C3503: ??? (in /home/geeknik/busybox/busybox)
==2822==    by 0x543D447: ???
==2822==    by 0x543D447: ???
==2822==    by 0x543D447: ???
==2822==  Address 0x0 is not stack'd, malloc'd or (recently) free'd
==2822== 
==2822== 
==2822== Process terminating with default action of signal 11 (SIGSEGV):
dumping core
==2822==  Access not within mapped region at address 0x0
==2822==    at 0x7C3503: ??? (in /home/geeknik/busybox/busybox)
==2822==    by 0x543D447: ???
==2822==    by 0x543D447: ???
==2822==    by 0x543D447: ???
==2822==  If you believe this happened as a result of a stack
==2822==  overflow in your program's main thread (unlikely but
==2822==  possible), you can try to increase the size of the
==2822==  main thread stack using the --main-stacksize= flag.
==2822==  The main thread stack size used in this run was 8388608.
Segmentation fault

The testcase is only 15 bytes and the command line used was "./busybox ash
test" and here we are.

Hexdump of testcase: 
0000000 2b2b 3c3c 0061 293b 1c28 3e20 2f24 0061
000000f

I believe the same crash happens with busybox sh as well. Wasn't sure if I
needed to open a 2nd bug for that

-- 
Configure bugmail: https://bugs.busybox.net/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.