Bug 24001 - A memory leak issue was discovered in function debug_init in debug.c
Summary: A memory leak issue was discovered in function debug_init in debug.c
Alias: None
Product: binutils
Classification: Unclassified
Component: binutils (show other bugs)
Version: 2.31
: P2 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
Depends on:
Reported: 2018-12-18 14:59 UTC by wcventure
Modified: 2019-01-04 12:21 UTC (History)
1 user (show)

See Also:
Last reconfirmed:

POC1 (63 bytes, application/octet-stream)
2018-12-18 14:59 UTC, wcventure
POC2 (72 bytes, application/octet-stream)
2018-12-18 14:59 UTC, wcventure

Note You need to log in before you can comment on or make changes to this bug.
Description wcventure 2018-12-18 14:59:41 UTC
Created attachment 11468 [details]

Hi there,

A memory leak issue was discovered in debug.c, as distributed in GNU Binutils 2.31. 
In debug_init function in debug.c, the is a heap allocation. But this heap allocation didn't deallocate in the end. The source Code show as follow.

> void *
> debug_init (void)
> {
>   struct debug_handle *ret;
>   ret = (struct debug_handle *) xmalloc (sizeof *ret);
>   memset (ret, 0, sizeof *ret);
>   return (void *) ret;
> }

Please use the "./objdump -xg $POC" to reproduce the bug.
To reproduce this bug. You need to build bintuils-2.31 with ASAN, setting following Command:

> export ASAN_OPTIONS=abort_on_error=1:symbolize=1:detect_leaks=1

The Leak Sanitizer dumps the stack trace as follows:

> =================================================================
> ==12163==ERROR: LeakSanitizer: detected memory leaks
> Direct leak of 96 byte(s) in 1 object(s) allocated from:
>     #0 0x7fcb75396602 in malloc (/usr/lib/x86_64-linux-gnu/libasan.so.2+0x98602)
>     #1 0x8f925b in xmalloc xmalloc.c:147
>     #2 0x4734b9 in debug_init /binutils-2.31_ASAN/binutils/debug.c:666
>     #3 0x47014b in read_debugging_info /binutils-2.31_ASAN/binutils/rddbg.c:51
>     #4 0x41e02c in dump_bfd objdump.c:3637
>     #5 0x41e30e in display_object_bfd objdump.c:3688
>     #6 0x41e89c in display_any_bfd objdump.c:3777
>     #7 0x41e936 in display_file objdump.c:3798
>     #8 0x41fb25 in main objdump.c:4100
>     #9 0x7fcb7404382f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2082f)
> SUMMARY: AddressSanitizer: 96 byte(s) leaked in 1 allocation(s).
Comment 1 wcventure 2018-12-18 14:59:59 UTC
Created attachment 11469 [details]
Comment 2 cvs-commit@gcc.gnu.org 2019-01-04 12:13:38 UTC
The master branch has been updated by Nick Clifton <nickc@sourceware.org>:


commit cf0ad5bbf2d3fdb751b5f3f49e55d251d48c7416
Author: Nick Clifton <nickc@redhat.com>
Date:   Fri Jan 4 12:11:51 2019 +0000

    Fix ridiculously small memory leak.
    	PR 24001
    	* objcopy.c (copy_object): Free dhandle after writing out the
    	debug information.
    	* objdump.c (dump_bfd): Free dhandle after printing out the debug
Comment 3 Nick Clifton 2019-01-04 12:21:48 UTC
Well this is the most trivial bug report that I have ever had to look at.  Honestly is it really worth reporting a memory leak of a few tens of bytes,
especially when they are released when the programs terminate ?

Anyway, I have gone ahead and fixed it because it was simple to trace down the uses of the allocated structure and add a couple of free() statements.