[Bug ld/23527] regression (ld-2.30 worked): relocation R_X86_64_PC32 against protected symbol `a' can not be used when making a shared object
https://sourceware.org/bugzilla/show_bug.cgi?id=23527 Sergei Trofimovich changed: What|Removed |Added CC||hjl.tools at gmail dot com --- Comment #2 from Sergei Trofimovich --- Bisected the change to: bd7ab16b4537788ad53521c45469a1bdae84ad4a is the first bad commit commit bd7ab16b4537788ad53521c45469a1bdae84ad4a Author: H.J. Lu Date: Tue Feb 13 07:34:22 2018 -0800 x86-64: Generate branch with PLT32 relocation Since there is no need to prepare for PLT branch on x86-64, generate R_X86_64_PLT32, instead of R_X86_64_PC32, if possible, which can be used as a marker for 32-bit PC-relative branches. -- 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/23527] regression (ld-2.30 worked): relocation R_X86_64_PC32 against protected symbol `a' can not be used when making a shared object
https://sourceware.org/bugzilla/show_bug.cgi?id=23527 --- Comment #3 from H.J. Lu --- (In reply to Sergei Trofimovich from comment #2) > Bisected the change to: > > bd7ab16b4537788ad53521c45469a1bdae84ad4a is the first bad commit > commit bd7ab16b4537788ad53521c45469a1bdae84ad4a > Author: H.J. Lu > Date: Tue Feb 13 07:34:22 2018 -0800 > > x86-64: Generate branch with PLT32 relocation > > Since there is no need to prepare for PLT branch on x86-64, generate > R_X86_64_PLT32, instead of R_X86_64_PC32, if possible, which can be > used as a marker for 32-bit PC-relative branches. This commit includes: PR gas/22791 * elf64-x86-64.c (is_32bit_relative_branch): Removed. (elf_x86_64_relocate_section): Check PIC relocations in PIE. Remove is_32bit_relative_branch usage. Disallow PC32 reloc against protected function in shared object. is_32bit_relative_branch is a kludge which is removed. R_X86_64_PLT32 should be used here as a marker for external branches. clang should be changed to generate R_X86_64_PLT32 for branches to external symbols. Or you can use GNU assembler to work around this issue. -- 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/23527] regression (ld-2.30 worked): relocation R_X86_64_PC32 against protected symbol `a' can not be used when making a shared object
https://sourceware.org/bugzilla/show_bug.cgi?id=23527
Sergei Trofimovich changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|--- |INVALID
--- Comment #4 from Sergei Trofimovich ---
Thank you! Looks like newest clang already adopted the change.
Closing as INVALID. I'll try to find exact llvm commit that fixed it.
$ cat a.c
void a(void) __attribute__((visibility("protected")));
void a(void){}
$ cat b.c
void a(void) __attribute__((visibility("protected")));
void b(void) __attribute__((visibility("protected")));
void b(void) { a(); }
$ cat a.sh
#!/bin/bash
for cc in gcc clang-8 clang-6.0; do
echo "cc=$cc"
$cc -O2 -fPIC -c a.c -o a.$cc.o
$cc -O2 -fPIC -c b.c -o b.$cc.o
#objdump -d -r a.o b.o
ld -shared \
-fPIC \
-o lib.$cc.so \
a.$cc.o b.$cc.o "$@"
done
$ LANG=C ./a.sh
cc=gcc
cc=clang-8
cc=clang-6.0
ld: b.clang-6.0.o: relocation R_X86_64_PC32 against protected symbol `a' can
not be used when making a shared object
ld: final link failed: bad value
--
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/23531] New: crash accessing address 0 in readelf (binutils-2.2.7a)
https://sourceware.org/bugzilla/show_bug.cgi?id=23531
Bug ID: 23531
Summary: crash accessing address 0 in readelf (binutils-2.2.7a)
Product: binutils
Version: unspecified
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: binutils
Assignee: unassigned at sourceware dot org
Reporter: l.simon at samsung dot com
Target Milestone: ---
Created attachment 11187
--> https://sourceware.org/bugzilla/attachment.cgi?id=11187&action=edit
input to reproduce the crash
Hi
I've come across an issue in readelf (binutils-2.2.7a), as follows:
Problem:
---
"readelf -a input" crashes trying to access uninitialised memory (0) if given
the file attached.
Reproduce:
-
$ CFLAGS="-g -fsanitize=address" CC=clang ../configure --disable-shared
--disable-nls --disable-werror --disable-gdb --disable-libdecnumber
--disable-readline --disable-sim
$ ASAN_SYMBOLIZER_PATH=`which llvm-symbolizer` ./build/binutils/readelf
-a input
==30209==ERROR: AddressSanitizer: SEGV on unknown address
0x (pc 0x0055c484 sp 0x7ffc692c6520 bp 0x7ffc692c6c50 T0)
#0 0x55c483 in dump_hppa_unwind
/path/binutils-2.2.7a.asan/build/binutils/../../binutils/readelf.c:7849
#1 0x553415 in hppa_process_unwind
/path/binutils-2.2.7a.asan/build/binutils/../../binutils/readelf.c:8129
#2 0x4b29f7 in process_unwind
/path/binutils-2.2.7a.asan/build/binutils/../../binutils/readelf.c:9262
#3 0x48c2d8 in process_object
/path/binutils-2.2.7a.asan/build/binutils/../../binutils/readelf.c:18751
#4 0x487870 in process_file
/path/binutils-2.2.7a.asan/build/binutils/../../binutils/readelf.c:19188
#5 0x485916 in main
/path/binutils-2.2.7a.asan/build/binutils/../../binutils/readelf.c:19247
#6 0x7f95f0d03f44 (/lib/x86_64-linux-gnu/libc.so.6+0x21f44)
#7 0x47e01c in _start
(/path/binutils-2.2.7a.asan/build/binutils/readelf+0x47e01c)
Details:
---
in file readelf.c, function hppa_process_unwind():
if (! slurp_hppa_unwind_table (filedata, &aux, sec))
res = FALSE;
if (aux.table_len > 0)
{
if (! dump_hppa_unwind (filedata, &aux))
res = FALSE;
}
[...]
Even if the function slurp_hppa_unwind_table() fails, the function
dump_hppa_unwind() is executed. In dump_hppa_unwind():
for (tp = aux->table; tp < aux->table + aux->table_len; ++tp)
{
bfd_vma offset;
const char * procname;
find_symbol_for_address (filedata, aux->funtab, aux->nfuns, aux->strtab,
aux->strtab_size, tp->start, &procname,
&offset);
[...]
Because slurp_hppa_unwind_table() failed, aux->table_len may be non-zero but
aux->table
is still 0. So tp is NULL and the program tries to access address 0x0.
I don't think this is exploitable because 0 is not controllable by user input:
it's the value
set in function hppa_process_unwind() thru:
memset (& aux, 0, sizeof (aux));
Suggested fix:
Change:
if ( aux.table_len > 0)
to:
if ( res && aux.table_len > 0)
Note: I reported this bug by email, and Nick Clifton
suggested the following fix:
diff --git a/binutils/readelf.c b/binutils/readelf.c
index 90dbdf7e2b..34acf6346a 100644
--- a/binutils/readelf.c
+++ b/binutils/readelf.c
@@ -7934,6 +7934,8 @@ slurp_hppa_unwind_table (Filedata *
filedata,
Elf_Internal_Sym * sym;
const char * relname;
+ aux->table_len = 0;
+
/* First, find the starting address of the segment that includes
this section. */
if (filedata->file_header.e_phnum)
However I don't think this fixes the problem, because:
1. The code I'm using already has the suggested fix
2. The length is updated in slurp_hppa_unwind_table(), but the function returns
FALSE before aux->table is populated with the corresponding entries. That's
where the mismatch comes from.
So the loop "for (tp = aux->table; tp < aux->table + aux->table_len; ++tp)" is
executed because the "aux->table_len" is non-zero. But aux->table is 0.
--
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/23527] regression (ld-2.30 worked): relocation R_X86_64_PC32 against protected symbol `a' can not be used when making a shared object
https://sourceware.org/bugzilla/show_bug.cgi?id=23527 --- Comment #5 from Sergei Trofimovich --- (In reply to Sergei Trofimovich from comment #4) > I'll try to find exact llvm commit that fixed it. Found it: commit 930bcc9bdfb9542a292c3de874d7e6ba1464cfe0 Author: George Rimar Date: Tue Feb 20 10:17:57 2018 + [llvm-mc] - Produce R_X86_64_PLT32 for "call/jmp foo". For instructions like call foo and jmp foo patch changes relocation produced from R_X86_64_PC32 to R_X86_64_PLT32. Relocation can be used as a marker for 32-bit PC-relative branches. Linker will reduce PLT32 relocation to PC32 if function is defined locally. Differential revision: https://reviews.llvm.org/D43383 -- 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
