----- "Adrien Kunysz" <adk@xxxxxxxxxx> 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. -- Crash-utility mailing list Crash-utility@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/crash-utility
