[Bug binutils/24644] OOM-Bug in _bfd_archive_64_bit_slurp_armap in bfd/archive64.c
https://sourceware.org/bugzilla/show_bug.cgi?id=24644 Alan Modra changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||amodra at gmail dot com Resolution|--- |INVALID --- Comment #1 from Alan Modra --- Out of memory is uninteresting unless it is triggered by a bug in binutils code that incorrectly calculates the amount of memory needed. -- 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/24644] New: OOM-Bug in _bfd_archive_64_bit_slurp_armap in bfd/archive64.c
https://sourceware.org/bugzilla/show_bug.cgi?id=24644 Bug ID: 24644 Summary: OOM-Bug in _bfd_archive_64_bit_slurp_armap in bfd/archive64.c Product: binutils Version: 2.33 (HEAD) Status: UNCONFIRMED Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: alex at forallsecure dot com Target Milestone: --- Created attachment 11819 --> https://sourceware.org/bugzilla/attachment.cgi?id=11819&action=edit Input to reproduce _bfd_archive_64_bit_slurp_armap reads nsymz from the archive, which is user controller. It then attempts to allocate an amount derived from nsymz, which allows attackers to trigger excessive memory consumption. I'm attaching a minimized input that triggers that issue. You can observe the behavior with `ltrace ./objdump -x ./input 2>&1 | grep malloc` or by compiling objdump with ASAN which produces the following stacktrace: ==39959==ERROR: AddressSanitizer: requested allocation size 0xa0a0a0a0a0a0a18 (0xa0a0a0a0a0a1a18 after adjustments for alignment, red zones etc.) exceeds maximum supported size of 0x100 (thread T0) #0 0x49665d in __interceptor_malloc /b/swarming/w/ir/k/src/third_party/llvm/compiler-rt/lib/asan/asan_malloc_linux.cc:145:3 #1 0x1148578 in _objalloc_alloc /fas/apr/binutils-gdb/build-libfuzzer/libiberty/../../libiberty/objalloc.c:143:22 #2 0x7f91d9 in bfd_alloc /fas/apr/binutils-gdb/build-libfuzzer/bfd/../../bfd/opncls.c:949:9 #3 0x7f8381 in bfd_zalloc /fas/apr/binutils-gdb/build-libfuzzer/bfd/../../bfd/opncls.c:998:9 #4 0x10c1636 in _bfd_archive_64_bit_slurp_armap /fas/apr/binutils-gdb/build-libfuzzer/bfd/../../bfd/archive64.c:98:39 #5 0x7d90c6 in bfd_slurp_armap /fas/apr/binutils-gdb/build-libfuzzer/bfd/../../bfd/archive.c:1149:14 #6 0x7d8a84 in bfd_generic_archive_p /fas/apr/binutils-gdb/build-libfuzzer/bfd/../../bfd/archive.c:875:8 #7 0x7f0da6 in bfd_check_format_matches /fas/apr/binutils-gdb/build-libfuzzer/bfd/../../bfd/format.c:315:14 - binutils version: commit 12efd68d159444ad8dfe24e49965a228ba980b86 (Wed Jun 5 2019) - OS: Ubuntu 18.04.2, running in a docker container on Mac OS - Linux 4.9.125-linuxkit - clang version 9.0.0 Found using ForAllSecure's Mayhem. -- 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/24643] New: arm/aarch64: SEGV in objdump -ld for static programs with split out debug symbols
https://sourceware.org/bugzilla/show_bug.cgi?id=24643
Bug ID: 24643
Summary: arm/aarch64: SEGV in objdump -ld for static programs
with split out debug symbols
Product: binutils
Version: 2.33 (HEAD)
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: binutils
Assignee: unassigned at sourceware dot org
Reporter: adam at os dot inf.tu-dresden.de
Target Milestone: ---
Created attachment 11816
--> https://sourceware.org/bugzilla/attachment.cgi?id=11816&action=edit
Patch to fix segfault
Hi,
objdump segfaults when using split out debug symbols and static programs on arm
and aarch64:
$ cat sh.sh
echo 'int main() { return 0; }' > foo.c
set -x
aarch64-linux-gnu-gcc -static -o foo-arm64 foo.c
objcopy --only-keep-debug foo-arm64 foo-arm64.debug
objcopy --strip-unneeded foo-arm64
objcopy --add-gnu-debuglink=foo-arm64.debug foo-arm64
objdump -ld foo-arm64
arm-linux-gnueabihf-gcc -static -o foo-arm32 foo.c
objcopy --only-keep-debug foo-arm32 foo-arm32.debug
objcopy --strip-unneeded foo-arm32
objcopy --add-gnu-debuglink=foo-arm32.debug foo-arm32
objdump -ld foo-arm32
$ sh sh.sh
+ aarch64-linux-gnu-gcc -static -o foo-arm64 foo.c
+ objcopy --only-keep-debug foo-arm64 foo-arm64.debug
+ objcopy --strip-unneeded foo-arm64
+ objcopy --add-gnu-debuglink=foo-arm64.debug foo-arm64
+ objdump -ld foo-arm64
foo-arm64: file format elf64-littleaarch64
Disassembly of section .init:
004001d8 <.init>:
sh.sh: line 7: 31282 Segmentation fault objdump -ld foo-arm64
+ arm-linux-gnueabihf-gcc -static -o foo-arm32 foo.c
+ objcopy --only-keep-debug foo-arm32 foo-arm32.debug
+ objcopy --strip-unneeded foo-arm32
+ objcopy --add-gnu-debuglink=foo-arm32.debug foo-arm32
+ objdump -ld foo-arm32
foo-arm32: file format elf32-littlearm
Disassembly of section .init:
00010140 <.init>:
sh.sh: line 13: 31291 Segmentation fault objdump -ld foo-arm32
$
Problem seems to be that aarch64_elf_find_function/arm_elf_find_function get
their symbols argument with NULL which the function is not prepared to handle.
Adding a check for NULL makes it work, see attached 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 ld/24613] ld --help for -z defs and --no-undefined
https://sourceware.org/bugzilla/show_bug.cgi?id=24613 --- Comment #5 from dilyan.palauzov at aegee dot org --- The descriptions of --no-undefined talks about regular object files, while --allow-shlib-undefined is about shared libraries as opposed to regular object files. -z undefs is about regular object files, both from executable and shared library. As for -z ..., the documentation of the other noX and X options is together, consider joining there the documentation for nodefs and defs. Honestly when linking I do not see why shall we talk about regular object files. Linking two object files, when the first file contains unresolved symbols and the second file defines that symbols, deserves no warning. The documentation of -z defs and --no-undefined says that the inverse is -z undefs, but the documentation of -z undefs says only -z defs is the inverse. Please clarify how --no-undefined and --allow-shlib-undefined are related: is the second complete subset of the former? Write down the behavior of ld.gold, when the specifics about ld.bfd are mentioned. What is a non-symbolic shared library? -- 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 gold/24642] New: Gold missing armv8 from may_use_v5t_interworking() results in less efficient v4t stubs
https://sourceware.org/bugzilla/show_bug.cgi?id=24642
Bug ID: 24642
Summary: Gold missing armv8 from may_use_v5t_interworking()
results in less efficient v4t stubs
Product: binutils
Version: unspecified
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: gold
Assignee: ccoutant at gmail dot com
Reporter: peter.smith at linaro dot org
CC: ian at airs dot com
Target Milestone: ---
In arm.cc the code that permits v5t interworking instructions is missing a case
for TAG_CPU_ARCH_V8 and the various V8_M mainline and baseline. As
--fix-arm1176 is the default this means that gold is using v4t stubs for arm v8
cpus. This is not a problem for correctness but v4t stubs and the non-use of
BLX is likely to have a measurable code-size and performance impact.
This can be worked around with -fno-fix-arm1176 but it should be simple to fix.
// Whether we have v5T interworking instructions available.
bool
may_use_v5t_interworking() const
{
Object_attribute* attr =
this->get_aeabi_object_attribute(elfcpp::Tag_CPU_arch);
int arch = attr->int_value();
if (parameters->options().fix_arm1176())
return (arch == elfcpp::TAG_CPU_ARCH_V6T2
|| arch == elfcpp::TAG_CPU_ARCH_V7
|| arch == elfcpp::TAG_CPU_ARCH_V6_M
|| arch == elfcpp::TAG_CPU_ARCH_V6S_M
|| arch == elfcpp::TAG_CPU_ARCH_V7E_M);
else
return (arch != elfcpp::TAG_CPU_ARCH_PRE_V4
&& arch != elfcpp::TAG_CPU_ARCH_V4
&& arch != elfcpp::TAG_CPU_ARCH_V4T);
}
A reproducer:
// call.c
extern void func1(void);
void func2(void) {
func1();
}
arm-linux-gnueabihf-gcc call.c -mthumb -o call.so --shared -fuse-ld=gold
-march=armv8-a -fpic
arm-linux-gnueabihf-objdump -d --no-show-raw-insn call.so
04c0 :
4c0: push{r7, lr}
4c2: add r7, sp, #0
4c4: bl 4cc
4c8: nop
4ca: pop {r7, pc}
4cc: bx pc
4ce: nop ; (mov r8, r8)
4d0: stmia r0!, {}
4d2: b.n 14 <_init-0x344>
4d4: blx 40f5f0 <_end+0x40d5c3>
4d8: mrc215, 5, pc, cr4, cr15, {7}
You can see the "bx pc" followed by "nop" of the v4t stub.
The stmia is Arm instructions disassembled as Thumb because there is no mapping
symbol to inform the disassembler that the state has changed.
--
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/24613] ld --help for -z defs and --no-undefined
https://sourceware.org/bugzilla/show_bug.cgi?id=24613 --- Comment #3 from Nick Clifton --- (In reply to dilyan.palau...@aegee.org from comment #2) > Either the > file shall describe how the linkers differ, or ld.gold shall provide its own > documentation. Or gold should be fixed to follow the same behaviour as ld.bfd. But I doubt that that last option will happen, so updating the documentation looks like the way to go. What do you think of the uploaded patch ? Cheers Nick -- 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/24613] ld --help for -z defs and --no-undefined
https://sourceware.org/bugzilla/show_bug.cgi?id=24613 --- Comment #4 from Nick Clifton --- Created attachment 11815 --> https://sourceware.org/bugzilla/attachment.cgi?id=11815&action=edit Proposed 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
