[Crash-utility] fuzzing crash(8)

[Dave Anderson]

----- "Adrien Kunysz" <adk at redhat.com> wrote:

> Adrien Kunysz wrote:
> > Actually that patch fixes all the crashes I found with my previous round 
> > of black box fuzzing on x86_64 (using zzuf if anyone is interested).  I 
> > am currently playing with bunny 
> > (http://code.google.com/p/bunny-the-fuzzer/) but I am a bit doubtful it 
> > will find anything useful in any decent amount of time without some 
> > manual work, oh well CPU time is cheap :)
> 
> I wasn't expecting Bunny to find anything for a few days but it only took
> about three hours :)
> 
> If we take the same x86_64 vmcore again:
> 
> 00000000  7f 45 4c 46 02 01 01 00  00 00 00 00 00 00 00 00  |.ELF............|
> 00000010  04 00 3e 00 01 00 00 00  00 00 00 00 00 00 00 00  |..>.............|
> 00000020  40 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |@...............|
> 00000030  00 00 00 00 40 00 38 00  03 80 00 00 00 00 00 00  |.... at .8.........|
> 
> and mess a bit with byte 0x39:
> 
> 00000000  7f 45 4c 46 02 01 01 00  00 00 00 00 00 00 00 00  |.ELF............|
> 00000010  04 00 3e 00 01 00 00 00  00 00 00 00 00 00 00 00  |..>.............|
> 00000020  40 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |@...............|
> 00000030  00 00 00 00 40 00 38 00  03 00 00 00 00 00 00 00  |.... at .8.........|
> 
> Program received signal SIGSEGV, Segmentation fault.
> dump_Elf64_Phdr (prog=0x7410fd8, store_pt_load_data=2193) at
> netdump.c:1456
> 1456                    pls->zero_fill = (prog->p_filesz == prog->p_memsz) ?
> (gdb) p prog
> $1 = (Elf64_Phdr *) 0x7410fd8
> (gdb) p *prog
> Cannot access memory at address 0x7410fd8
> (gdb) bt full
> #0  dump_Elf64_Phdr (prog=0x7410fd8, store_pt_load_data=2193) at
> netdump.c:1456
>          others = <value optimized out>
>          pls = (struct pt_load_segment *) 0x2aec420c9210
> #1  0x00000000004f1b9d in is_netdump (file=0x7fffdda29c03 "bit456",
> source_query=<value optimized out>)
>      at netdump.c:332
>          i = 2193
>          fd = <value optimized out>
>          swap = <value optimized out>
>          load32 = (Elf32_Phdr *) 0x0
>          load64 = (Elf64_Phdr *) 0x7fffdda27348
>          eheader = [...]
>          buf = [...]
>          size = 760
>          len = <value optimized out>
>          tot = <value optimized out>
>          offset32 = <value optimized out>
>          offset64 = <value optimized out>
>          tmp_flags = 64
>          tmp_elf_header = <value optimized out>
> #2  0x000000000044c852 in main (argc=2, argv=0x7fffdda28668) at
> main.c:401
>          i = <value optimized out>
>          c = <value optimized out>
>          option_index = 0
> (gdb) up
> #1  0x00000000004f1b9d in is_netdump (file=0x7fffdda29c03 "bit456",
> source_query=<value optimized out>)
>      at netdump.c:332
> 332                             dump_Elf64_Phdr(nd->load64 + i,
> ELFSTORE+i);
> (gdb) list
> 327                     if (DUMPFILE_FORMAT(nd->flags) ==
> NETDUMP_ELF64)
> 328                             nd->page_size =
> (uint)nd->load64->p_align;
> 329                     dump_Elf64_Ehdr(nd->elf64);
> 330                     dump_Elf64_Phdr(nd->notes64, ELFREAD);
> 331                     for (i = 0; i < nd->num_pt_load_segments;
> i++)
> 332                             dump_Elf64_Phdr(nd->load64 + i,
> ELFSTORE+i);
> 333                     offset64 = nd->notes64->p_offset;
> 334                     for (tot = 0; tot < nd->notes64->p_filesz; tot
> += len) {
> 335                             if (!(len = dump_Elf64_Nhdr(offset64,
> ELFSTORE)))
> 336                                     break;
> 
> I guess it means we need more sanity check on num_pt_load_segments
> (and I need to read the ELF specs).

I'm curious how "readelf -a" handle it?

I can't afford much time to look at these kinds of bugs at this
point in time.  Quite frankly, if somebody's purposely corrupting
vmcore file headers, it doesn't really bother me all that much if
it causes a segmentation violation -- especially if the vmcore is
going to be unusable anyway.

Anyway, let me know when you've got a patch ready for this one...  ;-)

Dave