fuzzing crash(8)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

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:

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.

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.

--
Crash-utility mailing list
Crash-utility@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/crash-utility

[Index of Archives]     [Fedora Development]     [Fedora Desktop]     [Fedora SELinux]     [Yosemite News]     [KDE Users]     [Fedora Tools]

 

Powered by Linux