[Bug gas/24010] New: macro.c get_any_string should check bounds in the while-loop
https://sourceware.org/bugzilla/show_bug.cgi?id=24010
Bug ID: 24010
Summary: macro.c get_any_string should check bounds in the
while-loop
Product: binutils
Version: 2.32 (HEAD)
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: gas
Assignee: unassigned at sourceware dot org
Reporter: wu.heng at zte dot com.cn
Target Milestone: ---
Created attachment 11476
--> https://sourceware.org/bugzilla/attachment.cgi?id=11476=edit
The fault sample
In the loop below, we do not think about the length of "idx > in->PTR", as the
in->PTR may not end in separator. We should add a judgment of "idx < in->len".
while (!ISSEP (in->ptr[idx]))
sb_add_char (out, in->ptr[idx++]);
here is the patch
diff --git a/gas/macro.c b/gas/macro.c
index 6c0e554..9b542e8 100644
--- a/gas/macro.c
+++ b/gas/macro.c
@@ -369,7 +369,7 @@ get_any_string (size_t idx, sb *in, sb *out)
{
if (in->len > idx + 2 && in->ptr[idx + 1] == '\'' && ISBASE
(in->ptr[idx]))
{
- while (!ISSEP (in->ptr[idx]))
+ while (idx < in->len && !ISSEP (in->ptr[idx]))
sb_add_char (out, in->ptr[idx++]);
}
else if (in->ptr[idx] == '%' && macro_alternate)
--
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/24010] macro.c get_any_string should check bounds in the while-loop
https://sourceware.org/bugzilla/show_bug.cgi?id=24010 wuheng changed: What|Removed |Added CC||wu.heng at zte dot com.cn -- 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/24009] read.c stringer should return when an error occured
https://sourceware.org/bugzilla/show_bug.cgi?id=24009 wuheng changed: What|Removed |Added CC||wu.heng at zte dot com.cn -- 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/24009] New: read.c stringer should return when an error occured
https://sourceware.org/bugzilla/show_bug.cgi?id=24009
Bug ID: 24009
Summary: read.c stringer should return when an error occured
Product: binutils
Version: 2.32 (HEAD)
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: gas
Assignee: unassigned at sourceware dot org
Reporter: wu.heng at zte dot com.cn
Target Milestone: ---
read.c stringer(): In the following fragment of the stringer(), the error
handling statement is missing, which result the var "input_line_pointer" read
out-of-bounds in SKIP_WHITESPACE() function.
case '<':
input_line_pointer++;
c = get_single_number ();
stringer_append_char (c, bitsize);
if (*input_line_pointer != '>')
as_bad (_("expected "));
input_line_pointer++;
//Should add "ignore_rest_of_line ();return;" before. Otherwise the
"input_line_pointer++" will out-of-bound and SKIP_WHITESPACE() will read
out-of-bounds then.
here is the patch:
diff --git a/gas/read.c b/gas/read.c
index 4a8b15a..fb5d612 100644
--- a/gas/read.c
+++ b/gas/read.c
@@ -5390,7 +5390,11 @@ stringer (int bits_appendzero)
c = get_single_number ();
stringer_append_char (c, bitsize);
if (*input_line_pointer != '>')
- as_bad (_("expected "));
+ {
+ as_bad (_("expected "));
+ ignore_rest_of_line ();
+ return;
+ }
input_line_pointer++;
break;
--
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 #10 from H.J. Lu --- (In reply to Ruslan Nikolaev from comment #9) > (In reply to H.J. Lu from comment #8) > > Fixed for 2.32. > > Thanks very much! Does it also fix the problem for i386 where an ordinary > func@plt is off by 4? Yes. -- 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 #9 from Ruslan Nikolaev --- (In reply to H.J. Lu from comment #8) > Fixed for 2.32. Thanks very much! Does it also fix the problem for i386 where an ordinary func@plt is off by 4? -- 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 #7 from cvs-commit at gcc dot gnu.org --- The master branch has been updated by H.J. Lu : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=b9519cfe9828b9ee5a73e74b4be83d46f33e6886 commit b9519cfe9828b9ee5a73e74b4be83d46f33e6886 Author: H.J. Lu Date: Wed Dec 19 12:21:56 2018 -0800 x86: Properly handle PLT expression in directive For PLT expressions, we should subtract the PLT relocation size only for jump instructions. Since PLT relocations are PC relative, we only allow "symbol@PLT" in PLT expression. gas/ PR gas/23997 * config/tc-i386.c (x86_cons): Check for invalid PLT expression. (md_apply_fix): Subtract the PLT relocation size only for jump instructions. * testsuite/gas/i386/reloc32.s: Add test for invalid PLT expression. * testsuite/gas/i386/reloc64.s: Likewise. * testsuite/gas/i386/ilp32/reloc64.s: Likewise. * testsuite/gas/i386/reloc32.l: Updated. * testsuite/gas/i386/reloc64.l: Likewise. * testsuite/gas/i386/ilp32/reloc64.l: Likewise. ld/ PR gas/23997 * testsuite/ld-i386/i386.exp: Run PR gas/23997 test. * testsuite/ld-x86-64/x86-64.exp: Likewise. * testsuite/ld-x86-64/pr23997a.s: New file. * testsuite/ld-x86-64/pr23997b.c: Likewise. * testsuite/ld-x86-64/pr23997c.c: Likewise. -- 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 H.J. Lu changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED Target Milestone|--- |2.32 --- Comment #8 from H.J. Lu --- Fixed for 2.32. -- 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 ld/22842] Handling of R_X86_64_PC32 in a PIE against a function in a shared library could be better
https://sourceware.org/bugzilla/show_bug.cgi?id=22842 --- Comment #14 from cvs-commit at gcc dot gnu.org --- The master branch has been updated by H.J. Lu : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=fc999e8020ffe8e1136da70f275bceafaa62a588 commit fc999e8020ffe8e1136da70f275bceafaa62a588 Author: H.J. Lu Date: Wed Dec 19 11:51:08 2018 -0800 Rename PR ld/22842 run-time test to "Run pr22842" * testsuite/ld-x86-64/x86-64.exp: Rename PR ld/22842 run-time test to "Run pr22842". -- 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 ld/24008] New: Wrong value of ternary expression in map file
https://sourceware.org/bugzilla/show_bug.cgi?id=24008 Bug ID: 24008 Summary: Wrong value of ternary expression in map file Product: binutils Version: 2.32 (HEAD) Status: UNCONFIRMED Severity: normal Priority: P2 Component: ld Assignee: unassigned at sourceware dot org Reporter: alfedotov at gmail dot com Target Milestone: --- If we have such expression in linker script: __TESTVAL1__ = 1; __TESTVAL2__ = 2; __TESTVAL__ = DEFINED ( __TESTVAL1__ ) ? (__TESTVAL1__) : (__TESTVAL2__); in final Map file output it always shows "else" branch: 0x0001 __TESTVAL1__ = 0x1 0x0002 __TESTVAL2__ = 0x2 0x0002 __TESTVAL__ = DEFINED (__TESTVAL1__)?__TESTVAL1__:__TESTVAL2__ While disassembling final ELF shows: 0001 g *ABS* __TESTVAL__ 0001 g *ABS* __TESTVAL1__ 0002 g *ABS* __TESTVAL2__ -- 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/24007] New: Multiple memory leak in ld
https://sourceware.org/bugzilla/show_bug.cgi?id=24007 Bug ID: 24007 Summary: Multiple memory leak in ld 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 11475 --> https://sourceware.org/bugzilla/attachment.cgi?id=11475=edit POC Hi there, Multiple memory leak issues were discovered in ld, as distributed in GNU Binutils 2.31. There are many heap allocations. But these heap allocations didn't deallocate in the end. Please use the "./ld -E $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: > = > ==102337==ERROR: LeakSanitizer: detected memory leaks > > Direct leak of 5632 byte(s) in 1 object(s) allocated from: > #0 0x4db160 in realloc > /Git/llvm-6.0.1/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:107 > #1 0xcc43d3 in xrealloc /binutils-gdb/libiberty/./xmalloc.c:179:14 > #2 0x618386 in gldelf_x86_64_add_options > /binutils-gdb/ld/eelf_x86_64.c:7189:5 > #3 0x5e3315 in ldemul_add_options /binutils-gdb/ld/ldemul.c:140:5 > #4 0x53aa64 in parse_args /binutils-gdb/ld/lexsup.c:613:3 > #5 0x5b90f9 in main /binutils-gdb/ld/./ldmain.c:314:3 > #6 0x7f594974082f in __libc_start_main > (/lib/x86_64-linux-gnu/libc.so.6+0x2082f) > > Direct leak of 5568 byte(s) in 1 object(s) allocated from: > #0 0x4dace0 in malloc > /Git/llvm-6.0.1/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:88 > #1 0x539eb1 in parse_args /binutils-gdb/ld/lexsup.c:567:7 > #2 0x5b90f9 in main /binutils-gdb/ld/./ldmain.c:314:3 > #3 0x7f594974082f in __libc_start_main > (/lib/x86_64-linux-gnu/libc.so.6+0x2082f) > > Direct leak of 390 byte(s) in 12 object(s) allocated from: > #0 0x4dace0 in malloc > /Git/llvm-6.0.1/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:88 > #1 0xcc3fdf in xmalloc /binutils-gdb/libiberty/./xmalloc.c:147:12 > #2 0xcc4695 in xstrdup /binutils-gdb/libiberty/./xstrdup.c:34:24 > #3 0x52f4e7 in yylex /binutils-gdb/ld/ldlex.l:423:20 > #4 0x514ccd in yyparse /binutils-gdb/ld/ldgram.c:2292:16 > #5 0x5b9595 in main /binutils-gdb/ld/./ldmain.c:351:7 > #6 0x7f594974082f in __libc_start_main > (/lib/x86_64-linux-gnu/libc.so.6+0x2082f) > > Direct leak of 64 byte(s) in 1 object(s) allocated from: > #0 0x4db160 in realloc > /Git/llvm-6.0.1/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:107 > #1 0xcc43d3 in xrealloc /binutils-gdb/libiberty/./xmalloc.c:179:14 > #2 0x6182aa in gldelf_x86_64_add_options > /binutils-gdb/ld/eelf_x86_64.c:7186:25 > #3 0x5e3315 in ldemul_add_options /binutils-gdb/ld/ldemul.c:140:5 > #4 0x53aa64 in parse_args /binutils-gdb/ld/lexsup.c:613:3 > #5 0x5b90f9 in main /binutils-gdb/ld/./ldmain.c:314:3 > #6 0x7f594974082f in __libc_start_main > (/lib/x86_64-linux-gnu/libc.so.6+0x2082f) > > Direct leak of 47 byte(s) in 3 object(s) allocated from: > #0 0x4dace0 in malloc > /Git/llvm-6.0.1/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:88 > #1 0xcc3fdf in xmalloc /binutils-gdb/libiberty/./xmalloc.c:147:12 > #2 0xcc4695 in xstrdup /binutils-gdb/libiberty/./xstrdup.c:34:24 > #3 0x52ee71 in yylex /binutils-gdb/ld/ldlex.l:395:20 > #4 0x514ccd in yyparse /binutils-gdb/ld/ldgram.c:2292:16 > #5 0x5b9595 in main /binutils-gdb/ld/./ldmain.c:351:7 > #6 0x7f594974082f in __libc_start_main > (/lib/x86_64-linux-gnu/libc.so.6+0x2082f) > > Direct leak of 22 byte(s) in 2 object(s) allocated from: > #0 0x4dace0 in malloc > /Git/llvm-6.0.1/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:88 > #1 0xcc3fdf in xmalloc /binutils-gdb/libiberty/./xmalloc.c:147:12 > #2 0xcc4695 in xstrdup /binutils-gdb/libiberty/./xstrdup.c:34:24 > #3 0x52eb92 in yylex /binutils-gdb/ld/ldlex.l:377:20 > #4 0x514ccd in yyparse /binutils-gdb/ld/ldgram.c:2292:16 > #5 0x5b9595 in main /binutils-gdb/ld/./ldmain.c:351:7 > #6 0x7f594974082f in __libc_start_main > (/lib/x86_64-linux-gnu/libc.so.6+0x2082f) > > SUMMARY: AddressSanitizer: 11723 byte(s) leaked in 20 allocation(s). > Aborted The valgrind dumps the stack trace as follows: valgrind --tool=memcheck --leak-check=full ./ld -E $POC > ... > ... > ==103914== LEAK SUMMARY: > ==103914==definitely lost: 12,058 bytes in 89 blocks > ==103914==indirectly lost: 0 bytes in 0 blocks > ==103914== possibly lost: 0 bytes in 0 blocks > ==103914==still reachable: 165,693 bytes in 530 blocks > ==103914== suppressed: 0 bytes in 0 blocks > ==103914== Reachable blocks (those to which a
[Bug binutils/24005] objdump integer overflow in load_specific_debug_section
https://sourceware.org/bugzilla/show_bug.cgi?id=24005 ShengBo Yan changed: What|Removed |Added CC||yanshb at gmail dot com -- 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 #6 from Ruslan Nikolaev --- BTW, I did some further testing with i386. It seems for i386, things are also not consistent but the other way around. .long func@plt does not seem generate correct offset (even for PIC), but func@plt - . seems to always generate correct offset (even for PIC). For both i386 and x86-64, clang/LLVM generated correct offset in either case. So, I think, it may present some problem as i386 and x86_64 assembly code is often (at least partially) shared. -- 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
