[Bug binutils/24001] A memory leak issue was discovered in function debug_init in debug.c
https://sourceware.org/bugzilla/show_bug.cgi?id=24001 --- Comment #1 from wcventure --- Created attachment 11469 --> https://sourceware.org/bugzilla/attachment.cgi?id=11469&action=edit POC2 -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/24001] New: A memory leak issue was discovered in function debug_init in debug.c
https://sourceware.org/bugzilla/show_bug.cgi?id=24001
Bug ID: 24001
Summary: A memory leak issue was discovered in function
debug_init in debug.c
Product: binutils
Version: 2.31
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: binutils
Assignee: unassigned at sourceware dot org
Reporter: wcventure at 126 dot com
Target Milestone: ---
Created attachment 11468
--> https://sourceware.org/bugzilla/attachment.cgi?id=11468&action=edit
POC1
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).
--
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/24002] New: A memory leak issue was discovered in cplus-dem.c
https://sourceware.org/bugzilla/show_bug.cgi?id=24002 Bug ID: 24002 Summary: A memory leak issue was discovered in cplus-dem.c Product: binutils Version: 2.31 Status: UNCONFIRMED Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: wcventure at 126 dot com Target Milestone: --- Created attachment 11470 --> https://sourceware.org/bugzilla/attachment.cgi?id=11470&action=edit POC1 Hi there, A memory leak issue was discovered in cplus-dem.c, as distributed in GNU Binutils 2.31. In demangle_template function in cplus-dem.c, the are many heap allocations. But these heap allocations didn't deallocate in the end. Please use the "./c++filt -t < $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: > = > ==16096==ERROR: LeakSanitizer: detected memory leaks > > Direct leak of 8 byte(s) in 1 object(s) allocated from: > #0 0x7f1c50822602 in malloc > (/usr/lib/x86_64-linux-gnu/libasan.so.2+0x98602) > #1 0x8247c9 in xmalloc xmalloc.c:147 > #2 0x7cf501 in demangle_template cplus-dem.c:2228 > #3 0x7cb3a5 in demangle_signature cplus-dem.c:1691 > #4 0x7d39fd in iterate_demangle_function cplus-dem.c:2743 > #5 0x7d5e9e in demangle_prefix cplus-dem.c:2971 > #6 0x7c6dfa in internal_cplus_demangle cplus-dem.c:1253 > #7 0x7c4464 in cplus_demangle cplus-dem.c:918 > #8 0x4033b3 in demangle_it binutils-2.31_ASAN/binutils/cxxfilt.c:62 > #9 0x403f1f in main binutils-2.31_ASAN/binutils/cxxfilt.c:276 > #10 0x7f1c4f4cf82f in __libc_start_main > (/lib/x86_64-linux-gnu/libc.so.6+0x2082f) > > Indirect leak of 2 byte(s) in 1 object(s) allocated from: > #0 0x7f1c50822602 in malloc > (/usr/lib/x86_64-linux-gnu/libasan.so.2+0x98602) > #1 0x8247c9 in xmalloc xmalloc.c:147 > #2 0x7d0439 in demangle_template cplus-dem.c:2327 > #3 0x7cb3a5 in demangle_signature cplus-dem.c:1691 > #4 0x7d39fd in iterate_demangle_function cplus-dem.c:2743 > #5 0x7d5e9e in demangle_prefix cplus-dem.c:2971 > #6 0x7c6dfa in internal_cplus_demangle cplus-dem.c:1253 > #7 0x7c4464 in cplus_demangle cplus-dem.c:918 > #8 0x4033b3 in demangle_it binutils-2.31_ASAN/binutils/cxxfilt.c:62 > #9 0x403f1f in main binutils-2.31_ASAN/binutils/cxxfilt.c:276 > #10 0x7f1c4f4cf82f in __libc_start_main > (/lib/x86_64-linux-gnu/libc.so.6+0x2082f) > > SUMMARY: AddressSanitizer: 10 byte(s) leaked in 2 allocation(s). -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/24002] A memory leak issue was discovered in cplus-dem.c
https://sourceware.org/bugzilla/show_bug.cgi?id=24002 --- Comment #1 from wcventure --- Created attachment 11471 --> https://sourceware.org/bugzilla/attachment.cgi?id=11471&action=edit POC2 -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gas/23997] PLT32 relocation is off by 4
https://sourceware.org/bugzilla/show_bug.cgi?id=23997 --- Comment #2 from Ruslan Nikolaev --- Sometimes when the assembly code is for both PIC and non-PIC code, you may want to use this construction. I checked LLVM/clang; it compiles correct output in both cases. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/24005] objdump integer overflow in load_specific_debug_section
https://sourceware.org/bugzilla/show_bug.cgi?id=24005 --- Comment #1 from ShengBo Yan --- Created attachment 11474 --> https://sourceware.org/bugzilla/attachment.cgi?id=11474&action=edit patch -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/24005] New: objdump integer overflow in load_specific_debug_section
https://sourceware.org/bugzilla/show_bug.cgi?id=24005
Bug ID: 24005
Summary: objdump integer overflow in
load_specific_debug_section
Product: binutils
Version: 2.32 (HEAD)
Status: UNCONFIRMED
Severity: critical
Priority: P2
Component: binutils
Assignee: unassigned at sourceware dot org
Reporter: yanshb at gmail dot com
Target Milestone: ---
Created attachment 11473
--> https://sourceware.org/bugzilla/attachment.cgi?id=11473&action=edit
POC3
I use 32bit objdump in 64bit Ubuntu 16.04.4 LTS.
The source Code show as follow in objdump.c.
>2528 bfd_size_type amt;
>2543 amt = section->size + 1;
>2544 section->start = contents = malloc (amt);
>2545 section->user_data = sec;
>2546 if (amt == 0
>2547 || section->start == NULL
>2548 || !bfd_get_full_section_contents (abfd, sec, &contents))
>2549{
>2550 free_debug_section (debug);
Integer overflow when section->size is 0x in line 2543, it will trigger
heap overflow in bfd_get_full_section_contents in line 2548. Finally crash in
line 2550.
The part of crash output show as follow.
./objdump -g POC3
*** Error in `./objdump': free(): invalid next size (fast): 0x0a0d06b8 ***
=== Backtrace: =
/lib/i386-linux-gnu/libc.so.6(+0x67377)[0xf7d8a377]
/lib/i386-linux-gnu/libc.so.6(+0x6d2f7)[0xf7d902f7]
/lib/i386-linux-gnu/libc.so.6(+0x6dc31)[0xf7d90c31]
./binutils/objdump[0x804f2c9]
./binutils/objdump[0x804efb9]
./binutils/objdump[0x804f463]
./binutils/objdump[0x80a69f5]
./binutils/objdump[0x804f60f]
./binutils/objdump[0x805174f]
./binutils/objdump[0x805182f]
./binutils/objdump[0x8051a7e]
./binutils/objdump[0x8051aeb]
./binutils/objdump[0x8052458]
/lib/i386-linux-gnu/libc.so.6(__libc_start_main+0xf7)[0xf7d3b637]
./binutils/objdump[0x8049b51]
=== Memory map:
08048000-08246000 r-xp 08:22 438569
/e/vul/testcase/binutils/binutils-gdb/binutils/objdump
08246000-08247000 r--p 001fd000 08:22 438569
/e/vul/testcase/binutils/binutils-gdb/binutils/objdump
08247000-0824c000 rw-p 001fe000 08:22 438569
/e/vul/testcase/binutils/binutils-gdb/binutils/objdump
0824c000-08253000 rw-p 00:00 0
0a0c6000-0a0e7000 rw-p 00:00 0 [heap]
f790-f7921000 rw-p 00:00 0
f7921000-f7a0 ---p 00:00 0
f7adf000-f7afb000 r-xp 08:06 3802106
/lib/i386-linux-gnu/libgcc_s.so.1
f7afb000-f7afc000 r--p 0001b000 08:06 3802106
/lib/i386-linux-gnu/libgcc_s.so.1
f7afc000-f7afd000 rw-p 0001c000 08:06 3802106
/lib/i386-linux-gnu/libgcc_s.so.1
f7b22000-f7d22000 r--p 08:06 527047
/usr/lib/locale/locale-archive
f7d22000-f7d23000 rw-p 00:00 0
f7d23000-f7ed3000 r-xp 08:06 3805752
/lib/i386-linux-gnu/libc-2.23.so
f7ed3000-f7ed5000 r--p 001af000 08:06 3805752
/lib/i386-linux-gnu/libc-2.23.so
f7ed5000-f7ed6000 rw-p 001b1000 08:06 3805752
/lib/i386-linux-gnu/libc-2.23.so
f7ed6000-f7ed9000 rw-p 00:00 0
f7ed9000-f7edc000 r-xp 08:06 3805774
/lib/i386-linux-gnu/libdl-2.23.so
f7edc000-f7edd000 r--p 2000 08:06 3805774
/lib/i386-linux-gnu/libdl-2.23.so
f7edd000-f7ede000 rw-p 3000 08:06 3805774
/lib/i386-linux-gnu/libdl-2.23.so
f7efa000-f7efb000 rw-p 00:00 0
f7efb000-f7f02000 r--s 08:06 676504
/usr/lib/i386-linux-gnu/gconv/gconv-modules.cache
f7f02000-f7f03000 r--p 002d4000 08:06 527047
/usr/lib/locale/locale-archive
f7f03000-f7f04000 rw-p 00:00 0
f7f04000-f7f07000 r--p 00:00 0 [vvar]
f7f07000-f7f09000 r-xp 00:00 0 [vdso]
f7f09000-f7f2c000 r-xp 08:06 3805748
/lib/i386-linux-gnu/ld-2.23.so
f7f2c000-f7f2d000 r--p 00022000 08:06 3805748
/lib/i386-linux-gnu/ld-2.23.so
f7f2d000-f7f2e000 rw-p 00023000 08:06 3805748
/lib/i386-linux-gnu/ld-2.23.so
ffd91000-ffdb2000 rw-p 00:00 0
[stack]
Aborted
--
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gas/23997] PLT32 relocation is off by 4
https://sourceware.org/bugzilla/show_bug.cgi?id=23997 --- Comment #3 from H.J. Lu --- (In reply to Ruslan Nikolaev from comment #2) > Sometimes when the assembly code is for both PIC and non-PIC code, you may >From x86-64 psAB: name@PLT: specifies the offset to the PLT entry of symbol name from the current code location. "name@PLT - ." has undefined behavior. Can you just use name@PLT for both PIC and non-PIC codes? > want to use this construction. I checked LLVM/clang; it compiles correct > output in both cases. This isn't relevant. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gas/23997] PLT32 relocation is off by 4
https://sourceware.org/bugzilla/show_bug.cgi?id=23997 --- Comment #4 from Ruslan Nikolaev --- (In reply to H.J. Lu from comment #3) > (In reply to Ruslan Nikolaev from comment #2) > > Sometimes when the assembly code is for both PIC and non-PIC code, you may > > From x86-64 psAB: > > name@PLT: specifies the offset to the PLT entry of symbol name from the > current code > location. > > "name@PLT - ." has undefined behavior. Can you just use name@PLT for both > PIC and non-PIC codes? > It is possible but see below. > > want to use this construction. I checked LLVM/clang; it compiles correct > > output in both cases. > > This isn't relevant. I guess, I do not have a very strong opinion about that. But my concern is that the generated relocation is off by 4 which is not clear why; I discovered that by a mere chance. The LLVM behavior is probably more intuitive here but at the very least it would be good to error out rather than just silently generate an incorrect relocation. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gas/23997] PLT32 relocation is off by 4
https://sourceware.org/bugzilla/show_bug.cgi?id=23997 --- Comment #5 from Ruslan Nikolaev --- or another possibility -- is to output some warning -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
