Bug 1294264
| Summary: | NULL dereference in libdwarf ( tested in libdwarf-20151114) | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | xqx <xiaoqixue2008> | ||||
| Component: | libdwarf | Assignee: | Tom Hughes <tom> | ||||
| Status: | CLOSED RAWHIDE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
| Severity: | unspecified | Docs Contact: | |||||
| Priority: | unspecified | ||||||
| Version: | rawhide | CC: | anemec, orion, tom | ||||
| Target Milestone: | --- | Keywords: | Security, SecurityTracking | ||||
| Target Release: | --- | ||||||
| Hardware: | Unspecified | ||||||
| OS: | Unspecified | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | Release Note | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2015-12-31 08:05:39 UTC | Type: | Bug | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Bug Depends On: | |||||||
| Bug Blocks: | 1296986 | ||||||
| Attachments: |
|
||||||
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. |
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. ```