----- "Adrien Kunysz" <adk(a)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 |....@.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 |....@.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