Re: [Crash-utility] fuzzing crash(8)
by Dave Anderson
----- "Adrien Kunysz" <adk(a)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 |....@.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 |....@.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.
14 years, 7 months
- 1
- 0