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