[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