Created attachment 1109494 [details] the elf file with bug a null pointer dereference is found in libdwarf-20151114, and it also is found and tested in libdwarf-20150112. we guess that it may be exsit in all the versions between them. the bug is at line 454 in dwarf_utils.c as following code: dwarf_utils.c ``` 448 /* End of abbrev's as we are past the end entirely. 449 THis can happen */ 450 if (abbrev_ptr > end_abbrev_ptr) { 451 return (NULL); 452 } 453 /* End of abbrev's for this cu, since abbrev code is 0. */ 454 if (*abbrev_ptr == 0) { 455 return (NULL); 456 } ``` use valgrind dwardump -ka awbug6.elf. (please see attachment for awbug6.elf.) ``` ==70284== Invalid read of size 1 ==70284== at 0x449624: _dwarf_get_abbrev_for_code (dwarf_util.c:454) ==70284== by 0x4281D4: dwarf_siblingof_b (dwarf_die_deliv.c:1534) ==70284== by 0x40D9F5: print_one_die_section (print_die.c:604) ==70284== by 0x40CF23: print_infos (print_die.c:319) ==70284== by 0x4046D6: process_one_file (dwarfdump.c:1280) ==70284== by 0x403529: main (dwarfdump.c:630) ==70284== Address 0x0 is not stack'd, malloc'd or (recently) free'd ==70284== ==70284== ==70284== Process terminating with default action of signal 11 (SIGSEGV) ==70284== Access not within mapped region at address 0x0 ==70284== at 0x449624: _dwarf_get_abbrev_for_code (dwarf_util.c:454) ==70284== by 0x4281D4: dwarf_siblingof_b (dwarf_die_deliv.c:1534) ==70284== by 0x40D9F5: print_one_die_section (print_die.c:604) ==70284== by 0x40CF23: print_infos (print_die.c:319) ==70284== by 0x4046D6: process_one_file (dwarfdump.c:1280) ==70284== by 0x403529: main (dwarfdump.c:630) ==70284== If you believe this happened as a result of a stack ==70284== overflow in your program's main thread (unlikely but ==70284== possible), you can try to increase the size of the ==70284== main thread stack using the --main-stacksize= flag. ==70284== The main thread stack size used in this run was 8388608. ```
You'd be much better off reporting these upstream (see http://www.prevanders.net/dwarf.html for contact details) rather than reporting them here and letting me forward them.
The problem is that the debug_abbrev section is marked as NOBITS in the ELF file - in other words as a zero-init section rather than a section with contents in the file. You can see this with readelf: % readelf --debug-dump=abbrev awbug6.elf section '.debug_abbrev' has the NOBITS type - its contents are unreliable. That is clearly bogus, but obviously shouldn't crash and the crash has been reported upstream.
(In reply to Tom Hughes from comment #1) > You'd be much better off reporting these upstream (see > http://www.prevanders.net/dwarf.html for contact details) rather than > reporting them here and letting me forward them. Do you mean send email to libdwarf-list ? However, I had sent mail to this email but no reply received.
(In reply to Tom Hughes from comment #2) > The problem is that the debug_abbrev section is marked as NOBITS in the ELF > file - in other words as a zero-init section rather than a section with > contents in the file. You can see this with readelf: > > % readelf --debug-dump=abbrev awbug6.elf > section '.debug_abbrev' has the NOBITS type - its contents are unreliable. > > That is clearly bogus, but obviously shouldn't crash and the crash has been > reported upstream. yes, some bytes are changed from a real ELF file. but I think it may not result to a crash.
David tells me he has no record of any email from you, but he has now supplied a fix which is included in the libdwarf-20151114-3.fc24 build.