Bug 24057 - objdump memory leaks in xmalloc.c
Summary: objdump memory leaks in xmalloc.c
Status: RESOLVED WONTFIX
Alias: None
Product: binutils
Classification: Unclassified
Component: binutils (show other bugs)
Version: 2.31
: P2 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-01-03 17:38 UTC by zerokeeper
Modified: 2019-01-21 13:31 UTC (History)
1 user (show)

See Also:
Host:
Target:
Build:
Last reconfirmed:


Attachments
binutil-objdump-memory-leaks-xmalloc (10.81 KB, application/x-executable)
2019-01-03 17:38 UTC, zerokeeper
Details

Note You need to log in before you can comment on or make changes to this bug.
Description zerokeeper 2019-01-03 17:38:26 UTC
Created attachment 11508 [details]
binutil-objdump-memory-leaks-xmalloc

hi,binutils team.i found there is memory leaks in xmalloc.c, when used objdump. 
here is AddressSanitizer info.

./binutils/objdump  -W poc

.........
==24202==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 28672 byte(s) in 4 object(s) allocated from:
    #0 0x4b9708 in malloc (/root/fuzz/binutils-2.31/binutils/objdump+0x4b9708)
    #1 0x9b73cf in xrealloc /root/fuzz/binutils-2.31/libiberty/./xmalloc.c:177:14
    #2 0x50ae56 in read_and_display_attr /root/fuzz/binutils-2.31/binutils/dwarf.c:2696:10
    #3 0x50ae56 in process_debug_info /root/fuzz/binutils-2.31/binutils/dwarf.c:3206
    #4 0x5062cb in load_separate_debug_file /root/fuzz/binutils-2.31/binutils/dwarf.c:9937:11
    #5 0x4f2f45 in dump_dwarf /root/fuzz/binutils-2.31/binutils/./objdump.c:2766:15
    #6 0x4ee3be in display_object_bfd /root/fuzz/binutils-2.31/binutils/./objdump.c:3688:7
    #7 0x4ee3be in display_any_bfd /root/fuzz/binutils-2.31/binutils/./objdump.c:3777
    #8 0x4ed553 in display_file /root/fuzz/binutils-2.31/binutils/./objdump.c:3798:3
    #9 0x4ed553 in main /root/fuzz/binutils-2.31/binutils/./objdump.c:4100
    #10 0x7fa9ab24b82f in __libc_start_main /build/glibc-Cl5G7W/glibc-2.23/csu/../csu/libc-start.c:291

Direct leak of 408 byte(s) in 8 object(s) allocated from:
    #0 0x4b9708 in malloc (/root/fuzz/binutils-2.31/binutils/objdump+0x4b9708)
    #1 0x9b723a in xmalloc /root/fuzz/binutils-2.31/libiberty/./xmalloc.c:147:12
    #2 0x4f4a16 in dump_dwarf_section /root/fuzz/binutils-2.31/binutils/./objdump.c:2694:6

Direct leak of 96 byte(s) in 1 object(s) allocated from:
    #0 0x4b9708 in malloc (/root/fuzz/binutils-2.31/binutils/objdump+0x4b9708)
    #1 0x9b723a in xmalloc /root/fuzz/binutils-2.31/libiberty/./xmalloc.c:147:12
    #2 0x5117c8 in display_debug_frames /root/fuzz/binutils-2.31/binutils/dwarf.c:7497:12
    #3 0x4f4a16 in dump_dwarf_section /root/fuzz/binutils-2.31/binutils/./objdump.c:2694:6

Indirect leak of 204 byte(s) in 4 object(s) allocated from:
    #0 0x4b9a88 in realloc (/root/fuzz/binutils-2.31/binutils/objdump+0x4b9a88)
    #1 0x9b73aa in xrealloc /root/fuzz/binutils-2.31/libiberty/./xmalloc.c:179:14

Indirect leak of 96 byte(s) in 1 object(s) allocated from:
    #0 0x4b9708 in malloc (/root/fuzz/binutils-2.31/binutils/objdump+0x4b9708)
    #1 0x9b723a in xmalloc /root/fuzz/binutils-2.31/libiberty/./xmalloc.c:147:12
    #2 0x5117c8 in display_debug_frames /root/fuzz/binutils-2.31/binutils/dwarf.c:7497:12
    #3 0x4f4a16 in dump_dwarf_section /root/fuzz/binutils-2.31/binutils/./objdump.c:2694:6

SUMMARY: AddressSanitizer: 29476 byte(s) leaked in 18 allocation(s).


for example,source code in /binutils-2.31/libiberty/./xmalloc.c:177:14
https://github.com/bminor/binutils-gdb/blob/master/libiberty/xmalloc.c#L177

xrealloc (PTR oldmem, size_t size)
{
  PTR newmem;

  if (size == 0)
    size = 1;
  if (!oldmem)
    newmem = malloc (size);
  else
    newmem = realloc (oldmem, size);
  if (!newmem)
    xmalloc_failed (size);

  return (newmem);
}
Comment 1 Nick Clifton 2019-01-21 13:31:09 UTC
Hi zerokeeper,

  Thanks for reporting this problem.  Unfortunately memory leaks like
  this are just not worth fixing.  The objdump program does not run
  continuously, and any memory that it does not free itself will be
  released once it terminates.  Thus I can see no real need to investigate
  of fix issues like this.

Cheers
  Nick