Bug 1294264 - NULL dereference in libdwarf ( tested in libdwarf-20151114)
Summary: NULL dereference in libdwarf ( tested in libdwarf-20151114)
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: libdwarf
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Tom Hughes
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: CVE-2015-8750
TreeView+ depends on / blocked
 
Reported: 2015-12-26 01:14 UTC by xqx
Modified: 2016-01-08 15:59 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Release Note
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-12-31 08:05:39 UTC


Attachments (Terms of Use)
the elf file with bug (2.92 KB, application/zip)
2015-12-26 01:14 UTC, xqx
no flags Details

Description xqx 2015-12-26 01:14:08 UTC
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.
```

Comment 1 Tom Hughes 2015-12-27 09:37:08 UTC
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.

Comment 2 Tom Hughes 2015-12-30 09:33:30 UTC
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.

Comment 3 xqx 2015-12-30 14:39:11 UTC
(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@earthlink.net ? However, I had sent mail to this email but no reply received.

Comment 4 xqx 2015-12-30 14:44:07 UTC
(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.

Comment 5 Tom Hughes 2015-12-31 08:05:39 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.