[Crash-utility] fuzzing crash(8)

Dave Anderson anderson at redhat.com
Tue Dec 1 14:27:55 UTC 2009


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

> Earlier today I was pointed to a truncated vmcore that made crash(8)
> crash and this prompted me to do some fuzzing. 
> Before going further I would like to know if there is interest to fix
> this kind of bugs and if I should report them to 
> Bugzilla. After all, most of these crashes are unlikely to happen in
> real life as long as the vmcores have not been 
> purposefully tempered with.

Exactly.  So let's just fix it.

> 
> The most common crash by far in my tests is this one:
> 
> Consider a x86_64 vmcore file taken with the snap plugin:
> 
> 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.........|
> 00000040  04 00 00 00 00 00 00 00  e8 00 00 00 00 00 00 00  |................|
> 
> If we change byte 0x4e:
> 
> 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.........|
> 00000040  04 00 00 00 00 00 00 00  e8 00 00 00 00 00 80 00  |................|
> 
> This makes crash(8) segfault:
> 

Right -- I can see that when you hand-set the PT_NOTE segment's p_offset field
to some bizarre value, it caused a reference outside of the 760-bye allocated
header.  I presume that the fix would be to have dump_Elf64_Nhdr() return immediately
at line 1803, i.e. instead of setting "remaining" to 0 and then waiting until
making it to line 1809 to print the error message and then return.

Does that work?

Dave


> Program received signal SIGSEGV, Segmentation fault.
> 0x00000000004f1bf4 in dump_Elf64_Nhdr (offset=36028797018964200, store=1) at netdump.c:1807
> 1807            notesize = (uint64_t)note->n_namesz + (uint64_t)note->n_descsz;
> (gdb) bt full
> #0  0x00000000004f1bf4 in dump_Elf64_Nhdr (offset=36028797018964200, store=1) at netdump.c:1807
>          i = 0
>          lf = 0
>          words = 0
>          note = (Elf64_Nhdr *) 0x800000159520c8
>          len = 140737175810672
>          buf = '\0' <repeats 1499 times>
>          ptr = 0x800000159520d4 <Address 0x800000159520d4 out of bounds>
>          uptr = (ulonglong *) 0x100000000
>          iptr = (int *) 0x0
>          up = (ulong *) 0x6f0617
>          xen_core = 0
>          vmcoreinfo = 0
>          remaining = 0
>          notesize = 362094736
> #1  0x00000000004ed99a in is_netdump (file=0x7fffed5f1bee "vmcore-sample-small.x86_64", source_query=128) at netdump.c:335
>          i = 2
>          fd = 6
>          swap = 0
>          elf32 = (Elf32_Ehdr *) 0x7fffed5ef8b0
>          load32 = (Elf32_Phdr *) 0x0
>          elf64 = (Elf64_Ehdr *) 0x7fffed5ef8b0
>          load64 = (Elf64_Phdr *) 0x7fffed5ef928
>          eheader = [...]
>          buf = [...]
>          size = 760
>          len = 0
>          tot = 0
>          offset32 = 32767
>          offset64 = 36028797018964200
>          tmp_flags = 64
>          tmp_elf_header = 0x15951fe0 "\177ELF\002\001\001"
> #2  0x00000000004f3e3b in is_kdump (file=0x7fffed5f1bee "vmcore-sample-small.x86_64", source_query=128) at netdump.c:2383
> No locals.
> #3  0x000000000044c892 in main (argc=2, argv=0x7fffed5f0cb8) at
> main.c:401
>          i = <value optimized out>
>          c = <value optimized out>
>          option_index = 0
> 
> It looks like it should do more sanity check on p_offset but I am
> unsure how to fix this properly.

I would guess that the 
> 
> This is crash-4.1.1-0. The sample vmcore is too large to send by mail
> or to attach to Bugzilla and I am not sure the 
> crash core itself would be of much use.




More information about the Crash-utility mailing list