[Bug binutils/24242] New: readelf: heap buffer overflow in byte_get_little_endian

2019-02-19 Thread spinpx at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=24242

Bug ID: 24242
   Summary: readelf: heap buffer overflow in
byte_get_little_endian
   Product: binutils
   Version: 2.33 (HEAD)
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: binutils
  Assignee: unassigned at sourceware dot org
  Reporter: spinpx at gmail dot com
  Target Milestone: ---

Created attachment 11622
  --> https://sourceware.org/bugzilla/attachment.cgi?id=11622=edit
Heap buffer overflow input

- Intel Xeon Gold 5118 processors and 256 GB memory
- Linux n18-065-139 4.19.0-1-amd64 #1 SMP Debian 4.19.12-1 (2018-12-22) x86_64
GNU/Linux
- clang version 4.0.0 (tags/RELEASE_400/final)
- version: commit c72e75a64030b0f6535a80481f37968ad55c333a (Feb 19 2019)
- run: readelf -a input_file

- asan_report:
ELF Header:
  Magic:   7f 45 4c 46 01 01 01 00 00 00 00 00 34 00 20 e9 
  Class: ELF32
  Data:  2's complement, little endian
  Version:   1 (current)
  OS/ABI:UNIX - System V
  ABI Version:   0
  Type:  EXEC (Executable file)
  Machine:   Intel IA-64
  Version:   0xee01
  Entry point address:   0x8048074
  Start of program headers:  52 (bytes into file)
  Start of section headers:  164 (bytes into file)
  Flags: 0xde00, 32-bit
  Size of this header:   51 (bytes)
  Size of program headers:   32 (bytes)
  Number of program headers: 2
  Size of section headers:   40 (bytes)
  Number of section headers: 4
  Section header string table index: 3
readelf: Error: Reading 160 bytes extends past end of file for section headers
readelf: Error: Section headers are not available!
=
==328304==ERROR: AddressSanitizer: heap-buffer-overflow on address
0x60d000c1 at pc 0x005dd1d6 bp 0x7ffc427f3900 sp 0x7ffc427f38f8
READ of size 1 at 0x60d000c1 thread T0
#0 0x5dd1d5 in byte_get_little_endian
/mnt/raid/user/chenpeng/FuzzingBench/binutils/binutils-gdb/binutils/elfcomm.c:210:22
#1 0x56f778 in print_ia64_vms_note
/mnt/raid/user/chenpeng/FuzzingBench/binutils/binutils-gdb/binutils/readelf.c:17982:24
#2 0x56c09f in process_note
/mnt/raid/user/chenpeng/FuzzingBench/binutils/binutils-gdb/binutils/readelf.c:18579:12
#3 0x56a944 in process_notes_at
/mnt/raid/user/chenpeng/FuzzingBench/binutils/binutils-gdb/binutils/readelf.c:18769:13
#4 0x5693a9 in process_corefile_note_segments
/mnt/raid/user/chenpeng/FuzzingBench/binutils/binutils-gdb/binutils/readelf.c:18799:8
#5 0x5691c6 in process_note_sections
/mnt/raid/user/chenpeng/FuzzingBench/binutils/binutils-gdb/binutils/readelf.c:18927:12
#6 0x524199 in process_notes
/mnt/raid/user/chenpeng/FuzzingBench/binutils/binutils-gdb/binutils/readelf.c:18940:12
#7 0x505c9d in process_object
/mnt/raid/user/chenpeng/FuzzingBench/binutils/binutils-gdb/binutils/readelf.c:19303:9
#8 0x4f547d in process_file
/mnt/raid/user/chenpeng/FuzzingBench/binutils/binutils-gdb/binutils/readelf.c:19715:13
#9 0x4f3ec8 in main
/mnt/raid/user/chenpeng/FuzzingBench/binutils/binutils-gdb/binutils/readelf.c:19774:11
#10 0x7fe5604f009a in __libc_start_main
(/lib/x86_64-linux-gnu/libc.so.6+0x2409a)
#11 0x41d4b9 in _start
(/mnt/raid/user/chenpeng/FuzzingBench/build/asan/install/bin/readelf+0x41d4b9)

0x60d000c1 is located 0 bytes to the right of 129-byte region
[0x60d00040,0x60d000c1)
allocated by thread T0 here:
#0 0x4c41ac in malloc
/scratch/llvm/clang-4/xenial/final/llvm.src/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:66:3
#1 0x4f179f in get_data
/mnt/raid/user/chenpeng/FuzzingBench/binutils/binutils-gdb/binutils/readelf.c:426:9
#2 0x56965e in process_notes_at
/mnt/raid/user/chenpeng/FuzzingBench/binutils/binutils-gdb/binutils/readelf.c:18635:36
#3 0x5693a9 in process_corefile_note_segments
/mnt/raid/user/chenpeng/FuzzingBench/binutils/binutils-gdb/binutils/readelf.c:18799:8
#4 0x5691c6 in process_note_sections
/mnt/raid/user/chenpeng/FuzzingBench/binutils/binutils-gdb/binutils/readelf.c:18927:12
#5 0x524199 in process_notes
/mnt/raid/user/chenpeng/FuzzingBench/binutils/binutils-gdb/binutils/readelf.c:18940:12
#6 0x505c9d in process_object
/mnt/raid/user/chenpeng/FuzzingBench/binutils/binutils-gdb/binutils/readelf.c:19303:9
#7 0x4f547d in process_file
/mnt/raid/user/chenpeng/FuzzingBench/binutils/binutils-gdb/binutils/readelf.c:19715:13
#8 0x4f3ec8 in main
/mnt/raid/user/chenpeng/FuzzingBench/binutils/binutils-gdb/binutils/readelf.c:19774:11
#9 0x7fe5604f009a in __libc_start_main
(/lib/x86_64-linux-gnu/libc.so.6+0x2409a)

SUMMARY: AddressSanitizer: 

[Bug binutils/24241] New: bug-report:inline-asm generates object file error

2019-02-19 Thread rdmsr at protonmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=24241

Bug ID: 24241
   Summary: bug-report:inline-asm generates object file error
   Product: binutils
   Version: unspecified
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: binutils
  Assignee: unassigned at sourceware dot org
  Reporter: rdmsr at protonmail dot com
  Target Milestone: ---

please see details below:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89401

-- 
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/24144] Gnu ld for PDP-11 is creating corrupt output. NULL inserted in data section.

2019-02-19 Thread amodra at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=24144

Alan Modra  changed:

   What|Removed |Added

 CC||amodra at gmail dot com
   Severity|critical|normal

--- Comment #3 from Alan Modra  ---
If you attach your testcase object files to this bugzilla then people without a
pdp compiler might look at your bug..

-- 
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


Re: macOS-builds of libbfd contain unresolvable _libintl_dgettext symbol

2019-02-19 Thread Alan Modra
On Tue, Feb 19, 2019 at 05:06:08PM +0100, Michael Roitzsch wrote:
> My proposed fix is attached as a patch.

Applied.

-- 
Alan Modra
Australia Development Lab, IBM

___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils


[Bug binutils/24233] objdump: Out of memory in libbfd.c

2019-02-19 Thread amodra at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=24233

Alan Modra  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC|amodra at gmail dot com|
 Resolution|--- |FIXED
   Assignee|unassigned at sourceware dot org   |amodra at gmail dot com
   Target Milestone|--- |2.33

--- Comment #6 from Alan Modra  ---
objdump now reports that something went wrong when printing private headers.

-- 
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/24233] objdump: Out of memory in libbfd.c

2019-02-19 Thread cvs-commit at gcc dot gnu.org
https://sourceware.org/bugzilla/show_bug.cgi?id=24233

--- Comment #5 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=7d272a55caebfc26ab2e15d1e9439bac978b9bb7

commit 7d272a55caebfc26ab2e15d1e9439bac978b9bb7
Author: Alan Modra 
Date:   Wed Feb 20 12:06:31 2019 +1030

PR24233, Out of memory

PR 24233
* objdump.c (dump_bfd_private_header): Print warning if
bfd_print_private_bfd_data returns false.

-- 
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/24236] size: Heap buffer overflow in _bfd_archive_64_bit_slurp_armap

2019-02-19 Thread cvs-commit at gcc dot gnu.org
https://sourceware.org/bugzilla/show_bug.cgi?id=24236

--- Comment #2 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=8abac8031ed369a2734b1cdb7df28a39a54b4b49

commit 8abac8031ed369a2734b1cdb7df28a39a54b4b49
Author: Alan Modra 
Date:   Wed Feb 20 08:21:24 2019 +1030

PR24236, Heap buffer overflow in _bfd_archive_64_bit_slurp_armap

PR 24236
* archive64.c (_bfd_archive_64_bit_slurp_armap): Move code adding
sentinel NUL to string buffer nearer to loop where it is used.
Don't go past sentinel when scanning strings, and don't write
NUL again.
* archive.c (do_slurp_coff_armap): Simplify string handling to
archive64.c style.

-- 
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/24226] Need advise on the binutils problem that generating wrong instruction like lw a3,-2048(a5) on RISC-V backend

2019-02-19 Thread liuyingying19 at huawei dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=24226

--- Comment #5 from GraceLiu  ---
(In reply to Jim Wilson from comment #4)
> Yes, I'd call this a compiler bug.  It is triggered when we have a long long
> inside a packed structure compiled for a 32-bit target, where the long long
> must be partially contained in the first word of the struct, in which case
> the long long has a 1 in 1K chance of getting an address that will generate
> an overflow when resolving relocations.  That would explain why I haven't
> seen it before.  Too many low chance conditions to trigger easily.  The same
> problem could occur for a 64-bit target with a 128-bit type in a packed
> struct, but that is probably even more rare.
> 
> There is still a linker issue here, in that the linker should generate an
> error when the reloc overflows and computes the wrong address.
> 
> You can work around the compiler bug by forcing the variable to have 8-byte
> alignment.  This can be done with an attribute
> struct S0 g_3030 __attribute__ ((aligned(8))) = {0,-9L,-0,-22553,7,-841,1};
> But that may be impractical if you have no easy way to identify the
> variables that need to be "fixed" to avoid the compiler problem.
> 
> The compiler bug needs to be reported into the gcc bugzilla so it can be
> fixed there.


Thanks Jim for the advice. 
I will try to file a bug to gcc bugzilla.

-- 
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/24236] size: Heap buffer overflow in _bfd_archive_64_bit_slurp_armap

2019-02-19 Thread amodra at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=24236

Alan Modra  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |2.33

--- Comment #3 from Alan Modra  ---
Fixed

-- 
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/24191] Gold doesn't properly process relocations to deduplicated code

2019-02-19 Thread ccoutant at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=24191

Cary Coutant  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #1 from Cary Coutant  ---
Actually, I think it's ld.bfd that's wrong here.

Ideally, when we discard a code section, we would also discard its debug info.
But the debug info format doesn't easily support this, and it would be a major
undertaking to make the linker capable of parsing, editing, and rewriting the
debug info (and that would make the linker unbearably slow).

In lieu of that, when we have a reference from debug info to a discarded
section, we resolve it using a base address of 0. This is deliberate, and
the debugger is (or should be) aware of this, so that it can ignore the
orphaned debug info. For other references to the discarded section, we do
in fact resolve them to point to the kept copy, but for debug info, we
resolve to 0.

Imagine what would happen if two copies of a function were compiled with
different optimization levels (or other options that would affect the code
generation). The line number tables (as well as any range information for
nested blocks inside the function) would differ, and it would be incorrect
for the discarded copy's debug info to be resolved to the kept copy of the
function. If the debugger were to find the mismatched line table while
doing an address-to-source-line lookup, it would then get the wrong answer.

-- 
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/23870] gold does not resolve the address of main when main is in a shared library

2019-02-19 Thread ccoutant at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=23870

Cary Coutant  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #4 from Cary Coutant  ---
Fixed on trunk.

-- 
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/23870] gold does not resolve the address of main when main is in a shared library

2019-02-19 Thread cvs-commit at gcc dot gnu.org
https://sourceware.org/bugzilla/show_bug.cgi?id=23870

--- Comment #3 from cvs-commit at gcc dot gnu.org  ---
The master branch has been updated by Cary Coutant :

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=7ae39e2d406dbec568c5ffd462119037b994fdf9

commit 7ae39e2d406dbec568c5ffd462119037b994fdf9
Author: Egeyar Bagcioglu 
Date:   Tue Feb 19 16:12:44 2019 -0800

Check whether symbols with MOVW_.ABS relocations require PLT entries
(aarch64).

2019-02-19  Egeyar Bagcioglu  

gold/
 PR gold/23870
 * aarch64.cc (Target_aarch64::Scan::global): Check if a symbol with
 R_AARCH64_MOVW_.ABS_* relocations requires a PLT entry.
 * testsuite/Makefile.am: Add aarch64_pr23870 test case.
 * testsuite/Makefile.in: Regenerate.
 * testsuite/aarch64_pr23870_bar.c: New file.
 * testsuite/aarch64_pr23870_foo.c: New file.
 * testsuite/aarch64_pr23870_main.S: New file.

-- 
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/23646] gold segfault when using --threads

2019-02-19 Thread ccoutant at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=23646

Cary Coutant  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2019-02-20
 Ever confirmed|0   |1

-- 
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/24238] size: Out of memory in libbfd

2019-02-19 Thread amodra at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=24238

Alan Modra  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||amodra at gmail dot com
 Resolution|--- |WONTFIX

--- Comment #1 from Alan Modra  ---
This is a different testcase and different out of memory condition to pr24233. 
Unlike pr24233 we report an out of memory error.  I think that is perfectly
good behaviour for user input with silly sizes, in this case a NOTE section
claiming to be 0xf7dd00 bytes in size.  While we could test for silly
section sizes by comparing against file size, that doesn't work in all
situations, eg. when section contents are encoded and the decoded size is much
larger than the raw size.

-- 
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/24232] objdump: Out of memory in objalloc.c

2019-02-19 Thread amodra at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=24232

--- Comment #5 from Alan Modra  ---
*** Bug 24237 has been marked as a duplicate of this bug. ***

-- 
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/24237] size: Out of memory in objalloc.c

2019-02-19 Thread amodra at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=24237

Alan Modra  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||amodra at gmail dot com
 Resolution|--- |DUPLICATE

--- Comment #2 from Alan Modra  ---
This is exactly the same "bug" as 24232 but with a slightly different testcase.

*** This bug has been marked as a duplicate of bug 24232 ***

-- 
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/24236] size: Heap buffer overflow in _bfd_archive_64_bit_slurp_armap

2019-02-19 Thread amodra at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=24236

Alan Modra  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-02-19
   Assignee|unassigned at sourceware dot org   |amodra at gmail dot com
 Ever confirmed|0   |1

-- 
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/24226] Need advise on the binutils problem that generating wrong instruction like lw a3,-2048(a5) on RISC-V backend

2019-02-19 Thread wilson at gcc dot gnu.org
https://sourceware.org/bugzilla/show_bug.cgi?id=24226

--- Comment #4 from Jim Wilson  ---
Yes, I'd call this a compiler bug.  It is triggered when we have a long long
inside a packed structure compiled for a 32-bit target, where the long long
must be partially contained in the first word of the struct, in which case the
long long has a 1 in 1K chance of getting an address that will generate an
overflow when resolving relocations.  That would explain why I haven't seen it
before.  Too many low chance conditions to trigger easily.  The same problem
could occur for a 64-bit target with a 128-bit type in a packed struct, but
that is probably even more rare.

There is still a linker issue here, in that the linker should generate an error
when the reloc overflows and computes the wrong address.

You can work around the compiler bug by forcing the variable to have 8-byte
alignment.  This can be done with an attribute
struct S0 g_3030 __attribute__ ((aligned(8))) = {0,-9L,-0,-22553,7,-841,1};
But that may be impractical if you have no easy way to identify the variables
that need to be "fixed" to avoid the compiler problem.

The compiler bug needs to be reported into the gcc bugzilla so it can be fixed
there.

-- 
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/23947] objcopy refuses to copy !(SEC_LOAD|SEC_ALLOC) sections

2019-02-19 Thread nickc at redhat dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=23947

Nick Clifton  changed:

   What|Removed |Added

 CC||nickc at redhat dot com

--- Comment #1 from Nick Clifton  ---
(In reply to Paul Pluzhnikov from comment #0)
Hi Paul,

> On Fedora, /usr/bin/ls has a mini-symbols .gnu_debugdata section:
> I wanted to examine the contents of this section, so I did the usual:
> 
>   objcopy -O binary -j.gnu_debuglink /usr/bin/ls /tmp/ls.mini.xz

Did you know that you can dump the contents of the .gnu.debuglink section
using readelf ?  For example:

  % readelf --debug-dump=links /usr/bin/ls
  Contents of the .gnu_debuglink section:

Separate debug info file: ls-8.30-6.fc29.x86_64.debug
CRC value: 0x98ccdd5c

> but that produced an empty file.
> AFAICT, this is happening because of the following check in bfd/binary.c:
> 
> 284 /* We don't want to output anything for a section that is neither
> 285loaded nor allocated.  The contents of such a section are not
> 286meaningful in the binary format.  */
> 287 if ((sec->flags & (SEC_LOAD | SEC_ALLOC)) == 0)
> 288   return TRUE;


> The statement that "contents is not meaningful in binary format" seems to be
> patently false (or rather, assumes that "binary" is going to be used for a
> specific purpose different from mine).
> 
> This appears to have been broken since forever:

Yeah - it has been this way for a very long time.  You can work around the 
problem however, by adding a section flag.  For example:

  % objcopy -j.gnu_debuglink --set-section-flags .gnu_debuglink=A /usr/bin/ls
fred
  % od fred
  000 071554 034055 031456 026460 027066 061546 034462 074056
  020 033070 033137 027064 062544 072542 000147 156534 114314
  040

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 binutils/24220] [2.32 Regression] gdb cannot read read separate debug info generated by binutils 2.32

2019-02-19 Thread nickc at redhat dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=24220

Nick Clifton  changed:

   What|Removed |Added

 CC||nickc at redhat dot com

--- Comment #3 from Nick Clifton  ---
(In reply to Matthias Klose from comment #2)
> hmm, this works with a gdb built from the trunk

Does this mean that this is a GDB issue ?  

Which version of GDB were you using when you discovered the failure ?
Assuming that it was from a branch of GDB, then it is likely that the
problem has been fixed on the mainline but not backported to that
branch.  Check out PR 23919 as a possible culprit.

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 binutils/24233] objdump: Out of memory in libbfd.c

2019-02-19 Thread spinpx at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=24233

--- Comment #4 from spinpx  ---
size can also trigger this:
https://sourceware.org/bugzilla/show_bug.cgi?id=24238

-- 
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/24238] New: size: Out of memory in libbfd

2019-02-19 Thread spinpx at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=24238

Bug ID: 24238
   Summary: size: Out of memory in libbfd
   Product: binutils
   Version: 2.33 (HEAD)
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: binutils
  Assignee: unassigned at sourceware dot org
  Reporter: spinpx at gmail dot com
  Target Milestone: ---

Created attachment 11620
  --> https://sourceware.org/bugzilla/attachment.cgi?id=11620=edit
OOM input

size also has the OOM issue described in
https://sourceware.org/bugzilla/show_bug.cgi?id=24233


- Intel Xeon Gold 5118 processors and 256 GB memory
- Linux n18-065-139 4.19.0-1-amd64 #1 SMP Debian 4.19.12-1 (2018-12-22) x86_64
GNU/Linux
- clang version 4.0.0 (tags/RELEASE_400/final)
- version: commit c72e75a64030b0f6535a80481f37968ad55c333a (Feb 19 2019)
- run: size input_file


==1671718==ERROR: AddressSanitizer failed to allocate 0xf8
(1099511103488) bytes of LargeMmapAllocator (error code: 12)
==1671718==Process memory map follows:
0x0040-0x0041d000  
/mnt/raid/user/chenpeng/FuzzingBench/build/asan/install/bin/size
0x0041d000-0x008b3000  
/mnt/raid/user/chenpeng/FuzzingBench/build/asan/install/bin/size
0x008b3000-0x00987000  
/mnt/raid/user/chenpeng/FuzzingBench/build/asan/install/bin/size
0x00988000-0x00989000  
/mnt/raid/user/chenpeng/FuzzingBench/build/asan/install/bin/size
0x00989000-0x009e8000  
/mnt/raid/user/chenpeng/FuzzingBench/build/asan/install/bin/size
0x009e8000-0x01654000   
0x7fff7000-0x8fff7000   
0x8fff7000-0x02008fff7000   
0x02008fff7000-0x10007fff8000   
0x6000-0x6020   
0x6020-0x6021   
0x6021-0x602e   
0x602e-0x602e0001   
0x602e0001-0x6030   
0x6030-0x6031   
0x6031-0x603e   
0x603e-0x603e0001   
0x603e0001-0x6040   
0x6040-0x6041   
0x6041-0x604e   
0x604e-0x604e0001   
0x604e0001-0x6070   
0x6070-0x6071   
0x6071-0x607e   
0x607e-0x607e0001   
0x607e0001-0x6080   
0x6080-0x6081   
0x6081-0x608e   
0x608e-0x608e0001   
0x608e0001-0x60b0   
0x60b0-0x60b1   
0x60b1-0x60be   
0x60be-0x60be0001   
0x60be0001-0x60c0   
0x60c0-0x60c1   
0x60c1-0x60ce   
0x60ce-0x60ce0001   
0x60ce0001-0x60f0   
0x60f0-0x60f1   
0x60f1-0x60fe   
0x60fe-0x60fe0001   
0x60fe0001-0x6100   
0x6100-0x6101   
0x6101-0x610e   
0x610e-0x610e0001   
0x610e0001-0x6110   
0x6110-0x6111   
0x6111-0x611e   
0x611e-0x611e0001   
0x611e0001-0x6120   
0x6120-0x6121   
0x6121-0x612e   
0x612e-0x612e0001   
0x612e0001-0x6140   
0x6140-0x6141   
0x6141-0x614e   
0x614e-0x614e0001   
0x614e0001-0x6160   
0x6160-0x6161   
0x6161-0x616e   
0x616e-0x616e0001   
0x616e0001-0x6180   
0x6180-0x6181   
0x6181-0x618e   
0x618e-0x618e0001   
0x618e0001-0x61a0   
0x61a0-0x61a1   
0x61a1-0x61ae   
0x61ae-0x61ae0001   
0x61ae0001-0x61d0   
0x61d0-0x61d1   
0x61d1-0x61de   
0x61de-0x61de0001   
0x61de0001-0x61f0   
0x61f0-0x61f1   
0x61f1-0x61fe   
0x61fe-0x61fe0001   
0x61fe0001-0x6210   
0x6210-0x6211   
0x6211-0x621e   
0x621e-0x621e0001   
0x621e0001-0x6240   
0x6240-0x6241   
0x6241-0x624e   
0x624e-0x624e0001   
0x624e0001-0x6400   
0x6400-0x64003000   

[Bug binutils/24235] objdump: Read memory violation in libbfd.c

2019-02-19 Thread amodra at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=24235

Alan Modra  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED
   Assignee|unassigned at sourceware dot org   |amodra at gmail dot com

--- Comment #2 from Alan Modra  ---
Fixed.

-- 
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/24232] objdump: Out of memory in objalloc.c

2019-02-19 Thread spinpx at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=24232

--- Comment #4 from spinpx  ---
Related issue: https://sourceware.org/bugzilla/show_bug.cgi?id=24237

-- 
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/24237] size: Out of memory in objalloc.c

2019-02-19 Thread spinpx at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=24237

--- Comment #1 from spinpx  ---
Created attachment 11619
  --> https://sourceware.org/bugzilla/attachment.cgi?id=11619=edit
OOM input

-- 
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/24237] New: size: Out of memory in objalloc.c

2019-02-19 Thread spinpx at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=24237

Bug ID: 24237
   Summary: size: Out of memory in objalloc.c
   Product: binutils
   Version: 2.33 (HEAD)
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: binutils
  Assignee: unassigned at sourceware dot org
  Reporter: spinpx at gmail dot com
  Target Milestone: ---

size also has the OOM issue described in
https://sourceware.org/bugzilla/show_bug.cgi?id=24232

If the issue it in a library shared with nm and size and if other program use
it,  it will cause DOS attacks.

- Intel Xeon Gold 5118 processors and 256 GB memory
- Linux n18-065-139 4.19.0-1-amd64 #1 SMP Debian 4.19.12-1 (2018-12-22) x86_64
GNU/Linux
- clang version 4.0.0 (tags/RELEASE_400/final)
- version: commit c72e75a64030b0f6535a80481f37968ad55c333a (Feb 19 2019)
- run: size input_file


==1601289==ERROR: AddressSanitizer failed to allocate 0xfe01363000
(1090942021632) bytes of LargeMmapAllocator (error code: 12)
==1601289==Process memory map follows:
0x0040-0x0041d000  
/mnt/raid/user/chenpeng/FuzzingBench/build/asan/install/bin/size
0x0041d000-0x008b3000  
/mnt/raid/user/chenpeng/FuzzingBench/build/asan/install/bin/size
0x008b3000-0x00987000  
/mnt/raid/user/chenpeng/FuzzingBench/build/asan/install/bin/size
0x00988000-0x00989000  
/mnt/raid/user/chenpeng/FuzzingBench/build/asan/install/bin/size
0x00989000-0x009e8000  
/mnt/raid/user/chenpeng/FuzzingBench/build/asan/install/bin/size
0x009e8000-0x01654000   
0x7fff7000-0x8fff7000   
0x8fff7000-0x02008fff7000   
0x02008fff7000-0x10007fff8000   
0x6000-0x6020   
0x6020-0x6021   
0x6021-0x602e   
0x602e-0x602e0001   
0x602e0001-0x6030   
0x6030-0x6031   
0x6031-0x603e   
0x603e-0x603e0001   
0x603e0001-0x6040   
0x6040-0x6041   
0x6041-0x604e   
0x604e-0x604e0001   
0x604e0001-0x6060   
0x6060-0x6061   
0x6061-0x606e   
0x606e-0x606e0001   
0x606e0001-0x6070   
0x6070-0x6071   
0x6071-0x607e   
0x607e-0x607e0001   
0x607e0001-0x6080   
0x6080-0x6081   
0x6081-0x608e   
0x608e-0x608e0001   
0x608e0001-0x60b0   
0x60b0-0x60b1   
0x60b1-0x60be   
0x60be-0x60be0001   
0x60be0001-0x60c0   
0x60c0-0x60c1   
0x60c1-0x60ce   
0x60ce-0x60ce0001   
0x60ce0001-0x60f0   
0x60f0-0x60f1   
0x60f1-0x60fe   
0x60fe-0x60fe0001   
0x60fe0001-0x6100   
0x6100-0x6101   
0x6101-0x610e   
0x610e-0x610e0001   
0x610e0001-0x6110   
0x6110-0x6111   
0x6111-0x611e   
0x611e-0x611e0001   
0x611e0001-0x6120   
0x6120-0x6121   
0x6121-0x612e   
0x612e-0x612e0001   
0x612e0001-0x6140   
0x6140-0x6141   
0x6141-0x614e   
0x614e-0x614e0001   
0x614e0001-0x6160   
0x6160-0x6161   
0x6161-0x616e   
0x616e-0x616e0001   
0x616e0001-0x6180   
0x6180-0x6181   
0x6181-0x618e   
0x618e-0x618e0001   
0x618e0001-0x6190   
0x6190-0x6191   
0x6191-0x619e   
0x619e-0x619e0001   
0x619e0001-0x61a0   
0x61a0-0x61a1   
0x61a1-0x61ae   
0x61ae-0x61ae0001   
0x61ae0001-0x61b0   
0x61b0-0x61b1   
0x61b1-0x61be   
0x61be-0x61be0001   
0x61be0001-0x61d0   
0x61d0-0x61d1   
0x61d1-0x61de   
0x61de-0x61de0001   
0x61de0001-0x61f0   
0x61f0-0x61f1   

[Bug binutils/24235] objdump: Read memory violation in libbfd.c

2019-02-19 Thread cvs-commit at gcc dot gnu.org
https://sourceware.org/bugzilla/show_bug.cgi?id=24235

--- 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=179f2db0d9c397d7dd8a59907b84208b79f7f48c

commit 179f2db0d9c397d7dd8a59907b84208b79f7f48c
Author: Alan Modra 
Date:   Tue Feb 19 22:48:44 2019 +1030

PR24235, Read memory violation in pei-x86_64.c

PR 24235
* pei-x86_64.c (pex64_bfd_print_pdata_section): Correct checks
attempting to prevent read past end of section.

-- 
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/24236] size: Heap buffer overflow in _bfd_archive_64_bit_slurp_armap

2019-02-19 Thread spinpx at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=24236

--- Comment #1 from spinpx  ---
Created attachment 11618
  --> https://sourceware.org/bugzilla/attachment.cgi?id=11618=edit
input triggers the bug

-- 
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/24236] New: size: Heap buffer overflow in _bfd_archive_64_bit_slurp_armap

2019-02-19 Thread spinpx at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=24236

Bug ID: 24236
   Summary: size: Heap buffer overflow in
_bfd_archive_64_bit_slurp_armap
   Product: binutils
   Version: 2.33 (HEAD)
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: binutils
  Assignee: unassigned at sourceware dot org
  Reporter: spinpx at gmail dot com
  Target Milestone: ---

- Intel Xeon Gold 5118 processors and 256 GB memory
- Linux n18-065-139 4.19.0-1-amd64 #1 SMP Debian 4.19.12-1 (2018-12-22) x86_64
GNU/Linux
- clang version 4.0.0 (tags/RELEASE_400/final)
- version: commit c72e75a64030b0f6535a80481f37968ad55c333a (Feb 19 2019)
- run: size input_file

- Exploitable:
Description: Heap error
Short description: HeapError (10/22)
Hash: 0ab5d0005e74fc041576aa73a2a94770.f78de5a987638de0bf17f6470949c81d
Exploitability Classification: EXPLOITABLE
Explanation: The target's backtrace indicates that libc has detected a heap
error or that the target was executing a heap function when it stopped. This
could be due to heap corruption, passing a bad pointer to a heap function such
as free(), etc. Since heap errors might include buffer overflows,
use-after-free situations, etc. they are generally considered exploitable.
Other tags: AbortSignal (20/22)

- stack:
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1  0x7fb7ebcef535 in __GI_abort () at abort.c:79
#2  0x7fb7ebd46778 in __libc_message (action=action@entry=do_abort,
fmt=fmt@entry=0x7fb7ebe5128d \"%s\\n\") at ../sysdeps/posix/libc_fatal.c:181
#3  0x7fb7ebd4ce6a in malloc_printerr (str=str@entry=0x7fb7ebe53018
\"double free or corruption (!prev)\") at malloc.c:5341
#4  0x7fb7ebd4e98c in _int_free (av=0x7fb7ebe88c40 ,
p=0xc49ac0, have_lock=) at malloc.c:4309
#5  0x005b6a64 in objalloc_free (o=0xc46780) at
/mnt/raid/user/chenpeng/FuzzingBench/binutils/binutils-gdb/libiberty/objalloc.c:187
#6  0x004227f9 in _bfd_delete_bfd (abfd=0xc46660) at
/mnt/raid/user/chenpeng/FuzzingBench/binutils/binutils-gdb/bfd/opncls.c:126
#7  bfd_close_all_done (abfd=0xc46660) at
/mnt/raid/user/chenpeng/FuzzingBench/binutils/binutils-gdb/bfd/opncls.c:773
#8  0x004225e8 in bfd_close (abfd=0xc46660) at
/mnt/raid/user/chenpeng/FuzzingBench/binutils/binutils-gdb/bfd/opncls.c:735"
#9  0x004043dd in display_file (filename=0x7ffceb73e23b
\"/mnt/raid/user/chenpeng/FuzzingBench/size/crashes_matryoshka_cmin_crash/id:00-crash_2\")
at
/mnt/raid/user/chenpeng/FuzzingBench/binutils/binutils-gdb/binutils/size.c:409
#10 0x00403cc5 in main (argc=, argv=0x7fb7ebd048bb
<__GI_raise+267>) at
/mnt/raid/user/chenpeng/FuzzingBench/binutils/binutils-gdb/binutils/size.c:241"

- asan report:
==1423785==ERROR: AddressSanitizer: heap-buffer-overflow on address
0x62104e78 at pc 0x007f787c bp 0x7511d170 sp 0x7511d168
WRITE of size 1 at 0x62104e78 thread T0
#0 0x7f787b in _bfd_archive_64_bit_slurp_armap
/mnt/raid/user/chenpeng/FuzzingBench/binutils/binutils-gdb/bfd/archive64.c:126:15
#1 0x4fcfd6 in bfd_slurp_armap
/mnt/raid/user/chenpeng/FuzzingBench/binutils/binutils-gdb/bfd/archive.c:1152:14
#2 0x4fc895 in bfd_generic_archive_p
/mnt/raid/user/chenpeng/FuzzingBench/binutils/binutils-gdb/bfd/archive.c:875:8
#3 0x5207e5 in bfd_check_format_matches
/mnt/raid/user/chenpeng/FuzzingBench/binutils/binutils-gdb/bfd/format.c:315:14
#4 0x51f82e in bfd_check_format
/mnt/raid/user/chenpeng/FuzzingBench/binutils/binutils-gdb/bfd/format.c:94:10
#5 0x4f1eb5 in display_file
/mnt/raid/user/chenpeng/FuzzingBench/binutils/binutils-gdb/binutils/size.c:431:7
#6 0x4f1aa5 in main
/mnt/raid/user/chenpeng/FuzzingBench/binutils/binutils-gdb/binutils/size.c:260:7
#7 0x7f0399a5209a in __libc_start_main
(/lib/x86_64-linux-gnu/libc.so.6+0x2409a)
#8 0x41d5e9 in _start
(/mnt/raid/user/chenpeng/FuzzingBench/build/asan/install/bin/size+0x41d5e9)

0x62104e78 is located 0 bytes to the right of 4472-byte region
[0x62103d00,0x62104e78)
allocated by thread T0 here:
#0 0x4c42dc in malloc
/scratch/llvm/clang-4/xenial/final/llvm.src/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:66:3
#1 0x8affb0 in _objalloc_alloc
/mnt/raid/user/chenpeng/FuzzingBench/binutils/binutils-gdb/libiberty/objalloc.c:143:22
#2 0x52e450 in bfd_alloc
/mnt/raid/user/chenpeng/FuzzingBench/binutils/binutils-gdb/bfd/opncls.c:949:9
#3 0x52c5cc in bfd_zalloc
/mnt/raid/user/chenpeng/FuzzingBench/binutils/binutils-gdb/bfd/opncls.c:998:9
#4 0x7f74c7 in _bfd_archive_64_bit_slurp_armap
/mnt/raid/user/chenpeng/FuzzingBench/binutils/binutils-gdb/bfd/archive64.c:98:39
#5 0x4fcfd6 in bfd_slurp_armap
/mnt/raid/user/chenpeng/FuzzingBench/binutils/binutils-gdb/bfd/archive.c:1152:14
#6 0x4fc895 in bfd_generic_archive_p
/mnt/raid/user/chenpeng/FuzzingBench/binutils/binutils-gdb/bfd/archive.c:875:8
#7 0x5207e5 in 

[Bug binutils/24234] objdump: Out of memory in xmalloc.c

2019-02-19 Thread amodra at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=24234

Alan Modra  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||amodra at gmail dot com
 Resolution|--- |WONTFIX

--- Comment #2 from Alan Modra  ---
OK, so here I do get a fail.
binutils/objdump: out of memory allocating 365072220160 bytes after a total of
53248 bytes.

The file has a symbol table claiming to be 0xff byte in size, or
0xaa000 symbols, requiring that rather huge amount of memory.  Since this
is driven by user input rather than due to some bug in binutils, it is quite
reasonable to report an out of memory error and exit.

-- 
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/24233] objdump: Out of memory in libbfd.c

2019-02-19 Thread spinpx at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=24233

--- Comment #3 from spinpx  ---
(In reply to Alan Modra from comment #2)
> The testcase has a VERDEFS section claiming to be 0xff7f00 in size.  I
> suppose we should inform the user that they hit an out-of-memory here rather
> than just silently ignoring the failure.

Agree.

-- 
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/24232] objdump: Out of memory in objalloc.c

2019-02-19 Thread amodra at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=24232

Alan Modra  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #3 from Alan Modra  ---
Also, the out-of-memory failure results in a further series of error messages
starting with "corrupt size field in group section header: 0x6072740080".

-- 
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/24233] objdump: Out of memory in libbfd.c

2019-02-19 Thread amodra at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=24233

--- Comment #2 from Alan Modra  ---
The testcase has a VERDEFS section claiming to be 0xff7f00 in size.  I
suppose we should inform the user that they hit an out-of-memory here rather
than just silently ignoring the failure.

-- 
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/24233] objdump: Out of memory in libbfd.c

2019-02-19 Thread amodra at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=24233

Alan Modra  changed:

   What|Removed |Added

 CC||amodra at gmail dot com

--- Comment #1 from Alan Modra  ---
This also doesn't reproduce for me.

-- 
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/24232] objdump: Out of memory in objalloc.c

2019-02-19 Thread amodra at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=24232

Alan Modra  changed:

   What|Removed |Added

 CC||amodra at gmail dot com

--- Comment #2 from Alan Modra  ---
This doesn't reproduce for me, at least not on objdump built by gcc and without
the address sanitizer (which increases memory use).  Incidentally, hitting an
out of memory failure in objalloc_alloc is not a libiberty failure and so
should not be reported to the gcc project.

Also, out of memory failures triggered by user input are not that interesting. 
It is perfectly reasonable for objdump to return with "out of memory" on
objects with silly sizes.

-- 
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/24235] New: objdump: Read memory violation in libbfd.c

2019-02-19 Thread spinpx at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=24235

Bug ID: 24235
   Summary: objdump: Read memory violation in libbfd.c
   Product: binutils
   Version: 2.33 (HEAD)
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: binutils
  Assignee: unassigned at sourceware dot org
  Reporter: spinpx at gmail dot com
  Target Milestone: ---

Created attachment 11617
  --> https://sourceware.org/bugzilla/attachment.cgi?id=11617=edit
the input triggers the bug

- Intel Xeon Gold 5118 processors and 256 GB memory
- Linux n18-065-139 4.19.0-1-amd64 #1 SMP Debian 4.19.12-1 (2018-12-22) x86_64
GNU/Linux
- clang version 4.0.0 (tags/RELEASE_400/final)
- version: commit c72e75a64030b0f6535a80481f37968ad55c333a (Feb 19 2019)
- run objdump -x input_file

- asan report
==1161627==ERROR: AddressSanitizer: SEGV on unknown address 0x613000bbe0fe (pc
0x00607197 bp 0x7ffcfa7de560 sp 0x7ffcfa7de500 T0)
==1161627==The signal is caused by a READ memory access.
#0 0x607196 in bfd_getl32
/mnt/raid/user/chenpeng/FuzzingBench/binutils/binutils-gdb/bfd/libbfd.c:695:7
#1 0x896b30 in pex64_get_runtime_function
/mnt/raid/user/chenpeng/FuzzingBench/binutils/binutils-gdb/bfd/pei-x86_64.c:94:26
#2 0x88f222 in pex64_bfd_print_pdata_section
/mnt/raid/user/chenpeng/FuzzingBench/binutils/binutils-gdb/bfd/pei-x86_64.c:730:5
#3 0x88d555 in pex64_bfd_print_pdata
/mnt/raid/user/chenpeng/FuzzingBench/binutils/binutils-gdb/bfd/pei-x86_64.c:794:12
#4 0x8c3894 in _bfd_pex64_print_private_bfd_data_common
/mnt/raid/user/chenpeng/FuzzingBench/build/asan/binutils-gdb/bfd/pex64igen.c:2911:5
#5 0x895d94 in pe_print_private_bfd_data
/mnt/raid/user/chenpeng/FuzzingBench/binutils/binutils-gdb/bfd/peicode.h:336:8
#6 0x4f65d5 in dump_bfd_private_header
/mnt/raid/user/chenpeng/FuzzingBench/binutils/binutils-gdb/binutils/objdump.c:3181:3
#7 0x4f51f9 in dump_bfd
/mnt/raid/user/chenpeng/FuzzingBench/binutils/binutils-gdb/binutils/objdump.c:3782:5
#8 0x4f4c71 in display_object_bfd
/mnt/raid/user/chenpeng/FuzzingBench/binutils/binutils-gdb/binutils/objdump.c:3883:7
#9 0x4f4b67 in display_any_bfd
/mnt/raid/user/chenpeng/FuzzingBench/binutils/binutils-gdb/binutils/objdump.c:3973:5
#10 0x4f424a in display_file
/mnt/raid/user/chenpeng/FuzzingBench/binutils/binutils-gdb/binutils/objdump.c:3994:3
#11 0x4f3ab0 in main
/mnt/raid/user/chenpeng/FuzzingBench/binutils/binutils-gdb/binutils/objdump.c:4304:6
#12 0x7f659f6c409a in __libc_start_main
(/lib/x86_64-linux-gnu/libc.so.6+0x2409a)
#13 0x41d639 in _start
(/mnt/raid/user/chenpeng/FuzzingBench/build/asan/install/bin/objdump+0x41d639)

AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV
/mnt/raid/user/chenpeng/FuzzingBench/binutils/binutils-gdb/bfd/libbfd.c:695:7
in bfd_getl32
==1161627==ABORTING


- Exploitable
Description: Access violation on source operand
Short description: SourceAv (19/22)
Hash: bafff732c614888210a0d11ed0439a22.5360e10ba1488dec3bada789cf815760
Exploitability Classification: UNKNOWN
"Explanation: The target crashed on an access violation at an address matching
the source operand of the current instruction. This likely indicates a read
access violation.
Other tags: AccessViolation (21/22)

-- 
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/24234] objdump: Out of memory in xmalloc.c

2019-02-19 Thread spinpx at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=24234

--- Comment #1 from spinpx  ---
Also report on https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89398

-- 
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/24234] New: objdump: Out of memory in xmalloc.c

2019-02-19 Thread spinpx at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=24234

Bug ID: 24234
   Summary: objdump: Out of memory in xmalloc.c
   Product: binutils
   Version: 2.33 (HEAD)
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: binutils
  Assignee: unassigned at sourceware dot org
  Reporter: spinpx at gmail dot com
  Target Milestone: ---

Created attachment 11616
  --> https://sourceware.org/bugzilla/attachment.cgi?id=11616=edit
inputs trigger the bugs

- Intel Xeon Gold 5118 processors and 256 GB memory
- Linux n18-065-139 4.19.0-1-amd64 #1 SMP Debian 4.19.12-1 (2018-12-22) x86_64
GNU/Linux
- clang version 4.0.0 (tags/RELEASE_400/final)
- version: commit c72e75a64030b0f6535a80481f37968ad55c333a (Feb 19 2019)
- run objdump -x input_file

- asan report

==1247614==ERROR: AddressSanitizer failed to allocate 0x552000
(365072228352) bytes of LargeMmapAllocator (error code: 12)
==1247614==Process memory map follows:
0x0040-0x0041d000  
/mnt/raid/user/chenpeng/FuzzingBench/build/asan/install/bin/objdump
0x0041d000-0x00996000  
/mnt/raid/user/chenpeng/FuzzingBench/build/asan/install/bin/objdump
0x00996000-0x00bc9000  
/mnt/raid/user/chenpeng/FuzzingBench/build/asan/install/bin/objdump
0x00bca000-0x00bcb000  
/mnt/raid/user/chenpeng/FuzzingBench/build/asan/install/bin/objdump
0x00bcb000-0x00c78000  
/mnt/raid/user/chenpeng/FuzzingBench/build/asan/install/bin/objdump
0x00c78000-0x018e9000   
0x7fff7000-0x8fff7000   
0x8fff7000-0x02008fff7000   
0x02008fff7000-0x10007fff8000   
0x6000-0x6020   
0x6020-0x6021   
0x6021-0x602e   
0x602e-0x602e0001   
0x602e0001-0x6030   
0x6030-0x6031   
0x6031-0x603e   
0x603e-0x603e0001   
0x603e0001-0x6040   
0x6040-0x6041   
0x6041-0x604e   
0x604e-0x604e0001   
0x604e0001-0x6060   
0x6060-0x6061   
0x6061-0x606e   
0x606e-0x606e0001   
0x606e0001-0x6070   
0x6070-0x6071   
0x6071-0x607e   
0x607e-0x607e0001   
0x607e0001-0x6080   
0x6080-0x6081   
0x6081-0x608e   
0x608e-0x608e0001   
0x608e0001-0x60b0   
0x60b0-0x60b1   
0x60b1-0x60be   
0x60be-0x60be0001   
0x60be0001-0x60c0   
0x60c0-0x60c1   
0x60c1-0x60ce   
0x60ce-0x60ce0001   
0x60ce0001-0x60f0   
0x60f0-0x60f1   
0x60f1-0x60fe   
0x60fe-0x60fe0001   
0x60fe0001-0x6100   
0x6100-0x6101   
0x6101-0x610e   
0x610e-0x610e0001   
0x610e0001-0x6110   
0x6110-0x6111   
0x6111-0x611e   
0x611e-0x611e0001   
0x611e0001-0x6120   
0x6120-0x6121   
0x6121-0x612e   
0x612e-0x612e0001   
0x612e0001-0x6140   
0x6140-0x6141   
0x6141-0x614e   
0x614e-0x614e0001   
0x614e0001-0x6160   
0x6160-0x6161   
0x6161-0x616e   
0x616e-0x616e0001   
0x616e0001-0x6180   
0x6180-0x6181   
0x6181-0x618e   
0x618e-0x618e0001   
0x618e0001-0x6190   
0x6190-0x6191   
0x6191-0x619e   
0x619e-0x619e0001   
0x619e0001-0x61a0   
0x61a0-0x61a1   
0x61a1-0x61ae   
0x61ae-0x61ae0001   
0x61ae0001-0x61b0   
0x61b0-0x61b1   
0x61b1-0x61be   
0x61be-0x61be0001   
0x61be0001-0x61d0   
0x61d0-0x61d1   
0x61d1-0x61de   
0x61de-0x61de0001   
0x61de0001-0x61f0   
0x61f0-0x61f1   
0x61f1-0x61fe   

[Bug binutils/24233] New: objdump: Out of memory in libbfd.c

2019-02-19 Thread spinpx at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=24233

Bug ID: 24233
   Summary: objdump: Out of memory in libbfd.c
   Product: binutils
   Version: 2.33 (HEAD)
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: binutils
  Assignee: unassigned at sourceware dot org
  Reporter: spinpx at gmail dot com
  Target Milestone: ---

Created attachment 11615
  --> https://sourceware.org/bugzilla/attachment.cgi?id=11615=edit
inputs that trigger bugs

- Intel Xeon Gold 5118 processors and 256 GB memory
- Linux n18-065-139 4.19.0-1-amd64 #1 SMP Debian 4.19.12-1 (2018-12-22) x86_64
GNU/Linux
- clang version 4.0.0 (tags/RELEASE_400/final)
- version: commit c72e75a64030b0f6535a80481f37968ad55c333a (Feb 19 2019)
- run objdump -x input_file

- asan report
==1243005==ERROR: AddressSanitizer failed to allocate 0xffa000
(1099511603200) bytes of LargeMmapAllocator (error code: 12)
==1243005==Process memory map follows:
0x0040-0x0041d000  
/mnt/raid/user/chenpeng/FuzzingBench/build/asan/install/bin/objdump
0x0041d000-0x00996000  
/mnt/raid/user/chenpeng/FuzzingBench/build/asan/install/bin/objdump
0x00996000-0x00bc9000  
/mnt/raid/user/chenpeng/FuzzingBench/build/asan/install/bin/objdump
0x00bca000-0x00bcb000  
/mnt/raid/user/chenpeng/FuzzingBench/build/asan/install/bin/objdump
0x00bcb000-0x00c78000  
/mnt/raid/user/chenpeng/FuzzingBench/build/asan/install/bin/objdump
0x00c78000-0x018e9000   
0x7fff7000-0x8fff7000   
0x8fff7000-0x02008fff7000   
0x02008fff7000-0x10007fff8000   
0x6000-0x6020   
0x6020-0x6021   
0x6021-0x602e   
0x602e-0x602e0001   
0x602e0001-0x6030   
0x6030-0x6031   
0x6031-0x603e   
0x603e-0x603e0001   
0x603e0001-0x6040   
0x6040-0x6041   
0x6041-0x604e   
0x604e-0x604e0001   
0x604e0001-0x6060   
0x6060-0x6061   
0x6061-0x606e   
0x606e-0x606e0001   
0x606e0001-0x6070   
0x6070-0x6071   
0x6071-0x607e   
0x607e-0x607e0001   
0x607e0001-0x6080   
0x6080-0x6081   
0x6081-0x608e   
0x608e-0x608e0001   
0x608e0001-0x60b0   
0x60b0-0x60b1   
0x60b1-0x60be   
0x60be-0x60be0001   
0x60be0001-0x60c0   
0x60c0-0x60c1   
0x60c1-0x60ce   
0x60ce-0x60ce0001   
0x60ce0001-0x60f0   
0x60f0-0x60f1   
0x60f1-0x60fe   
0x60fe-0x60fe0001   
0x60fe0001-0x6100   
0x6100-0x6101   
0x6101-0x610e   
0x610e-0x610e0001   
0x610e0001-0x6110   
0x6110-0x6111   
0x6111-0x611e   
0x611e-0x611e0001   
0x611e0001-0x6120   
0x6120-0x6121   
0x6121-0x612e   
0x612e-0x612e0001   
0x612e0001-0x6140   
0x6140-0x6141   
0x6141-0x614e   
0x614e-0x614e0001   
0x614e0001-0x6160   
0x6160-0x6161   
0x6161-0x616e   
0x616e-0x616e0001   
0x616e0001-0x6180   
0x6180-0x6181   
0x6181-0x618e   
0x618e-0x618e0001   
0x618e0001-0x6190   
0x6190-0x6191   
0x6191-0x619e   
0x619e-0x619e0001   
0x619e0001-0x61a0   
0x61a0-0x61a1   
0x61a1-0x61ae   
0x61ae-0x61ae0001   
0x61ae0001-0x61b0   
0x61b0-0x61b1   
0x61b1-0x61be   
0x61be-0x61be0001   
0x61be0001-0x61d0   
0x61d0-0x61d1   
0x61d1-0x61de   
0x61de-0x61de0001   
0x61de0001-0x61f0   
0x61f0-0x61f1   
0x61f1-0x61fe   

[Bug binutils/24232] objdump: Out of memory in objalloc.c

2019-02-19 Thread spinpx at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=24232

--- Comment #1 from spinpx  ---
Also report on https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89396

-- 
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/24232] New: objdump: Out of memory in objalloc.c

2019-02-19 Thread spinpx at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=24232

Bug ID: 24232
   Summary: objdump: Out of memory in objalloc.c
   Product: binutils
   Version: 2.33 (HEAD)
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: binutils
  Assignee: unassigned at sourceware dot org
  Reporter: spinpx at gmail dot com
  Target Milestone: ---

- Intel Xeon Gold 5118 processors and 256 GB memory
- Linux n18-065-139 4.19.0-1-amd64 #1 SMP Debian 4.19.12-1 (2018-12-22) x86_64
GNU/Linux
- clang version 4.0.0 (tags/RELEASE_400/final)
- version: commit c72e75a64030b0f6535a80481f37968ad55c333a (Feb 19 2019)
- run objdump -x input_file

- asan report
==1221228==ERROR: AddressSanitizer failed to allocate 0xc0e4e83000
(828474142720) bytes of LargeMmapAllocator (error code: 12)
==1221228==Process memory map follows:
0x0040-0x0041d000  
/mnt/raid/user/chenpeng/FuzzingBench/build/asan/install/bin/objdump
0x0041d000-0x00996000  
/mnt/raid/user/chenpeng/FuzzingBench/build/asan/install/bin/objdump
0x00996000-0x00bc9000  
/mnt/raid/user/chenpeng/FuzzingBench/build/asan/install/bin/objdump
0x00bca000-0x00bcb000  
/mnt/raid/user/chenpeng/FuzzingBench/build/asan/install/bin/objdump
0x00bcb000-0x00c78000  
/mnt/raid/user/chenpeng/FuzzingBench/build/asan/install/bin/objdump
0x00c78000-0x018e9000   
0x7fff7000-0x8fff7000   
0x8fff7000-0x02008fff7000   
0x02008fff7000-0x10007fff8000   
0x6000-0x6020   
0x6020-0x6021   
0x6021-0x602e   
0x602e-0x602e0001   
0x602e0001-0x6030   
0x6030-0x6031   
0x6031-0x603e   
0x603e-0x603e0001   
0x603e0001-0x6040   
0x6040-0x6041   
0x6041-0x604e   
0x604e-0x604e0001   
0x604e0001-0x6060   
0x6060-0x6061   
0x6061-0x606e   
0x606e-0x606e0001   
0x606e0001-0x6070   
0x6070-0x6071   
0x6071-0x607e   
0x607e-0x607e0001   
0x607e0001-0x6080   
0x6080-0x6081   
0x6081-0x608e   
0x608e-0x608e0001   
0x608e0001-0x60b0   
0x60b0-0x60b1   
0x60b1-0x60be   
0x60be-0x60be0001   
0x60be0001-0x60c0   
0x60c0-0x60c1   
0x60c1-0x60ce   
0x60ce-0x60ce0001   
0x60ce0001-0x60f0   
0x60f0-0x60f1   
0x60f1-0x60fe   
0x60fe-0x60fe0001   
0x60fe0001-0x6100   
0x6100-0x6101   
0x6101-0x610e   
0x610e-0x610e0001   
0x610e0001-0x6110   
0x6110-0x6111   
0x6111-0x611e   
0x611e-0x611e0001   
0x611e0001-0x6120   
0x6120-0x6121   
0x6121-0x612e   
0x612e-0x612e0001   
0x612e0001-0x6140   
0x6140-0x6141   
0x6141-0x614e   
0x614e-0x614e0001   
0x614e0001-0x6160   
0x6160-0x6161   
0x6161-0x616e   
0x616e-0x616e0001   
0x616e0001-0x6180   
0x6180-0x6181   
0x6181-0x618e   
0x618e-0x618e0001   
0x618e0001-0x6190   
0x6190-0x6191   
0x6191-0x619e   
0x619e-0x619e0001   
0x619e0001-0x61a0   
0x61a0-0x61a1   
0x61a1-0x61ae   
0x61ae-0x61ae0001   
0x61ae0001-0x61b0   
0x61b0-0x61b1   
0x61b1-0x61be   
0x61be-0x61be0001   
0x61be0001-0x61d0   
0x61d0-0x61d1   
0x61d1-0x61de   
0x61de-0x61de0001   
0x61de0001-0x61f0   
0x61f0-0x61f1   
0x61f1-0x61fe   
0x61fe-0x61fe0001   
0x61fe0001-0x6210   
0x6210-0x6211   

[Bug binutils/24227] nm: stack overflow

2019-02-19 Thread spinpx at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=24227

--- Comment #4 from spinpx  ---
It can be reproduced in commit c72e75a64030b0f6535a80481f37968ad55c333a (Feb 19
2019)

-- 
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/24227] nm: stack overflow

2019-02-19 Thread spinpx at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=24227

--- Comment #3 from spinpx  ---
report on gcc: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89394

-- 
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/24229] nm: heap buffer overflow

2019-02-19 Thread spinpx at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=24229

--- Comment #2 from spinpx  ---
report on gcc: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89395

-- 
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