[Bug binutils/28694] New: stabs.c: Out-of-bounds write in stab_xcoff_builtin_type
https://sourceware.org/bugzilla/show_bug.cgi?id=28694 Bug ID: 28694 Summary: stabs.c: Out-of-bounds write in stab_xcoff_builtin_type Product: binutils Version: 2.38 (HEAD) Status: UNCONFIRMED Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: pmayorov at cloudlinux dot com Target Milestone: --- Created attachment 13851 --> https://sourceware.org/bugzilla/attachment.cgi?id=13851&action=edit PoC and ASAN report I found an out-of-bounds write to the array 'info->xcoff_types' in the function 'stab_xcoff_builtin_type' (binutils/stabs.c). Processing of typenum -34 results in overwriting of adjacent field 'info->tags' at line 3668: info->xcoff_types[-typenum] = rettype; This eventually leads to a segmentation fault due to illegal memory reference performed by the function 'finish_stab'. ASAN catches this as heap-buffer-overflow. Steps to reproduce: Build current verison of binutils with ASAN: ./configure --disable-shared --disable-gdb --disable-gdbserver CFLAGS="-ggdb -Wno-error -fsanitize=address -fsanitize-recover=address" CXXFLAGS="-ggdb -Wno-error -fsanitize=address -fsanitize-recover=address" make all Run inputs under ASAN: binutils/objdump -g ~/oob_write The proof-of-concept and ASAN report are attached. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/28689] p_align in ELF program headers should not exceed section alignment
https://sourceware.org/bugzilla/show_bug.cgi?id=28689
--- Comment #6 from H.J. Lu ---
(In reply to Fangrui Song from comment #5)
> (In reply to Fangrui Song from comment #4)
> > (In reply to H.J. Lu from comment #2)
> > > One problem:
> > > [...]
> > > File offsets are changed.
> >
> > For objcopy, it is important to not transform the file to decrease the
> > intrinsic max-page-size. This would make the output not runnable on the
> > originally supported systems.
> >
> > If ld decreases p_align to reduce wasted memory pages, can you describe how
> > the objcopy problem (inferring max-page-size) will be solved?
> > Note that max-page-size can be trick to infer in the -z noseparate-code
> > case.
>
> Maybe something like gcd({p_vaddr - p_offset}). If the gcd is 0, pick p_align
This is roughly what my patch does.
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug ld/28695] New: Linker doesn't warn p_align < sh_sh_addralign
https://sourceware.org/bugzilla/show_bug.cgi?id=28695
Bug ID: 28695
Summary: Linker doesn't warn p_align < sh_sh_addralign
Product: binutils
Version: 2.38 (HEAD)
Status: NEW
Severity: normal
Priority: P2
Component: ld
Assignee: unassigned at sourceware dot org
Reporter: hjl.tools at gmail dot com
Target Milestone: ---
[hjl@gnu-cfl-2 align-1]$ cat load.c
#include
#include
#include
#define ALIGN 0x20
int
__attribute__ ((weak))
is_aligned (void *p, int align)
{
return (((uintptr_t) p) & (align - 1)) != 0;
}
int foo __attribute__ ((aligned (ALIGN))) = 1;
int
main (void)
{
printf ("foo: %p\n", &foo);
if (is_aligned (&foo, ALIGN))
abort ();
return 0;
}
[hjl@gnu-cfl-2 align-1]$ make
gcc -O2 -fPIE -c -o load.o load.c
gcc -pie -Wl,-z,max-page-size=0x1000 -O2 -fPIE -o pie load.o
readelf -SW load.o | grep "\.data"
[ 2] .data PROGBITS 20 04 00 WA
0 0 2097152
readelf -lW pie | grep LOAD
LOAD 0x00 0x 0x 0x0006a8
0x0006a8 R 0x1000
LOAD 0x001000 0x1000 0x1000 0x0001bd
0x0001bd R E 0x1000
LOAD 0x002000 0x2000 0x2000 0x00010c
0x00010c R 0x1000
LOAD 0x002de0 0x3de0 0x3de0 0x000248
0x000248 RW 0x1000
LOAD 0x20 0x0020 0x0020 0x24
0x28 RW 0x1000
./pie
foo: 0x7f9fcb0fa000
make: *** [Makefile:9: all] Aborted (core dumped)
[hjl@gnu-cfl-2 align-1]$
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug binutils/28687] Undefined behavior in bfd/dwarf1.c
https://sourceware.org/bugzilla/show_bug.cgi?id=28687
--- Comment #1 from Nikita Popov ---
I've verified the case by performing these steps:
1) Configure the project:
binutils-gdb$ ./configure CFLAGS='-g -O2' CXXFLAGS='-g -O2' LDFLAGS='-g -O2'
host_configargs='--disable-option-checking --disable-silent-rules'
2) Observe compilation command for dwarf1.c; slightly modify it to produce
assembly listing instead:
binutils-gdb/bfd$ gcc -DHAVE_CONFIG_H -I. -DBINDIR=\"/usr/local/bin\"
-DLIBDIR=\"/usr/local/lib\" -I. -I. -I./../include -DHAVE_x86_64_elf64_vec
-DHAVE_i386_elf32_vec -DHAVE_iamcu_elf32_vec -DHAVE_x86_64_elf32_vec
-DHAVE_i386_pei_vec -DHAVE_x86_64_pe_vec -DHAVE_x86_64_pei_vec
-DHAVE_l1om_elf64_vec -DHAVE_k1om_elf64_vec -DHAVE_elf64_le_vec
-DHAVE_elf64_be_vec -DHAVE_elf32_le_vec -DHAVE_elf32_be_vec -W -Wall
-Wstrict-prototypes -Wmissing-prototypes -Wshadow -Wstack-usage=262144 -Werror
-I./../zlib -g -O2 -S dwarf1.c -o-
3) The C fragment
268:case FORM_BLOCK4:
269: if (xptr + 4 <= aDiePtrEnd)
270:{
271: block_len = bfd_get_32 (abfd, xptr);
272: if (xptr + block_len > aDiePtrEnd
273: || xptr + block_len < xptr)
274:return false;
275: xptr += block_len;
276:}
277: xptr += 4;
278: break;
is turned into
.LVL22:
.loc 1 272 0
movl%eax, %eax
addq%rax, %r14
.LVL23:
cmpq%r14, %r12
jb .L4
.LVL24:
.L19:
.loc 1 277 0
leaq4(%r14), %rbx
by gcc version 7.5.0 (Ubuntu 7.5.0-3ubuntu1~18.04)
Note that the condition 'xptr + block_len < xptr' is completely omitted as is
clear from the assembly location markers.
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug binutils/26206] Add pei-aarch64 support for native EFI support
https://sourceware.org/bugzilla/show_bug.cgi?id=26206 Nick Clifton changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #29 from Nick Clifton --- (In reply to Alexander von Gluck IV from comment #28) > it looks like this one was done and can be closed? :-) Music to my ears. :-) -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/28696] New: FAIL: .noinit sections
https://sourceware.org/bugzilla/show_bug.cgi?id=28696 Bug ID: 28696 Summary: FAIL: .noinit sections Product: binutils Version: 2.36.1 Status: NEW Severity: normal Priority: P2 Component: ld Assignee: unassigned at sourceware dot org Reporter: hjl.tools at gmail dot com CC: jozef.l at mittosystems dot com Target Milestone: --- Target: arm-linux-gnueabi arm-linux-gnueabi has FAIL: .noinit sections FAIL: .persistent sections -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/28684] [RISCV] 32-bit --enable-targets=all build breakage issue
https://sourceware.org/bugzilla/show_bug.cgi?id=28684 Jim Wilson changed: What|Removed |Added CC||wilson at gcc dot gnu.org --- Comment #1 from Jim Wilson --- I installed a 32-bit debian release on an old laptop so I could look at this. Building a riscv target works because riscv is forcing a 64-bit bfd. So it is only --enable-targets=all that fails because there is no riscv target check. A 64-bit host also forces a 64-bit bfd, so enable-targets=all works there. It is only 32-bit host --enable-targets=all builds without --enable-64-bit-bfd that are broken. There are other targets that behave the same like aarch64. So this is a narrow enough problem that it doesn't need to be fixed. Hence we don't need Nelson's bfd patch, and Andrew's gdb patch is OK. But we still need to fix the simulator build problem. The issue here is that bfd/opcodes/gdb/etc have support to disable a target that requires a 64-bit bfd, but sim does not. There are only 4 targets that require a 64-bit bfd and have a sim port: aarch64, bpf, mips*, riscv*. The aarch64 sim port builds, but can't run binaries, because the bfd support to detect an aarch64 binary is missing. If it could run, it can't disassemble as the opcodes disassembler support is missing. I suspect the mips* sim port is in the same situation, but ran into maintenance issues. I'm getting linker script related errors, and if I hack around those I get simulator memory region errors. I'm using scripts that used to work, so I think this is a general mips lack of maintenance issue. The bpf port is cgen generated, and is making direct calls into cgen functions in opcodes, so it fails to link. If it did link, it wouldn't be able to run programs as the bfd support is missing. And it wouldn't be able to disassemble. The riscv port is directly using the opcode table in opcodes for decoding instructions before executing them, so it doesn't link. If it did link, it wouldn't be able to run programs as the bfd support is missing, and wouldn't be able to disassemble instructions. Since the BFD64 sims aren't useful when built, I don't see the point in building them. I think we should consider this a sim bug, and should fix it by adding support to disable targets that require a 64-bit bfd. Since sim is part of gdb, we can probably copy the gdb configure support for this into sim. I will try to write a patch. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/28697] New: objdump doesn't look for separate debug styles using "build-id" style
https://sourceware.org/bugzilla/show_bug.cgi?id=28697 Bug ID: 28697 Summary: objdump doesn't look for separate debug styles using "build-id" style Product: binutils Version: 2.37 Status: UNCONFIRMED Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: travis.downs at gmail dot com Target Milestone: --- Created attachment 13856 --> https://sourceware.org/bugzilla/attachment.cgi?id=13856&action=edit uses the debuglink and build-id styles to build and strip a binary Support for the "build ID" style of separate debug lookup was added in 2017: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=2425a30e406a0523020b7e70abb864a06a45bb97 However, it seems to be used only for a few flags like -S, but it is ignored for others, like --syms. Using strace, one can see that for --syms it is only looks for the old style "debuglink" debug info. It never looks in the `.build-id` based paths even when the note is present. Find below a test program which shows the issue, based on strace output, chmod +x it and run. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/28694] stabs.c: Out-of-bounds write in stab_xcoff_builtin_type
https://sourceware.org/bugzilla/show_bug.cgi?id=28694 Alan Modra changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at sourceware dot org |amodra at gmail dot com Ever confirmed|0 |1 Last reconfirmed||2021-12-15 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/28694] stabs.c: Out-of-bounds write in stab_xcoff_builtin_type
https://sourceware.org/bugzilla/show_bug.cgi?id=28694 --- Comment #1 from cvs-commit at gcc dot gnu.org --- The master branch has been updated by Alan Modra : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=161e87d12167b1e36193385485c1f6ce92f74f02 commit 161e87d12167b1e36193385485c1f6ce92f74f02 Author: Alan Modra Date: Wed Dec 15 11:48:42 2021 +1030 PR28694, Out-of-bounds write in stab_xcoff_builtin_type PR 28694 * stabs.c (stab_xcoff_builtin_type): Make typenum unsigned. Negate typenum earlier, simplifying bounds checking. Correct off-by-one indexing. Adjust switch cases. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/28694] stabs.c: Out-of-bounds write in stab_xcoff_builtin_type
https://sourceware.org/bugzilla/show_bug.cgi?id=28694 Alan Modra changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED Target Milestone|--- |2.38 --- Comment #2 from Alan Modra --- Fixed. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/28698] New: objdump is very slow in some cases
https://sourceware.org/bugzilla/show_bug.cgi?id=28698 Bug ID: 28698 Summary: objdump is very slow in some cases Product: binutils Version: 2.38 (HEAD) Status: NEW Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: hjl.tools at gmail dot com Target Milestone: --- If a .o file has any symbols with many sections, objdump can be very slow. There are several causes. 1. There is if (sorted_symcount > 1) qsort (sorted_syms, sorted_symcount, sizeof (asymbol *), compare_symbols); is called on each text section. On a .o file with 139815 symbols and 148096 sections, each qsort can take a long time to run. 2. find_symbol_for_address also takes time to run. -- You are receiving this mail because: You are on the CC list for the bug.
