[Bug binutils/29647] New: [Infinite Loop]: objdump(version 2.39.50.20221003, commit e1fc9bcf)
https://sourceware.org/bugzilla/show_bug.cgi?id=29647
Bug ID: 29647
Summary: [Infinite Loop]: objdump(version 2.39.50.20221003,
commit e1fc9bcf)
Product: binutils
Version: 2.40 (HEAD)
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: binutils
Assignee: unassigned at sourceware dot org
Reporter: chkunq at gmail dot com
Target Milestone: ---
Created attachment 14374
--> https://sourceware.org/bugzilla/attachment.cgi?id=14374&action=edit
An input file that triggers an infinite loop in objdump.
# Crash Inputs
The file that triggers the bug is attached in attachment.
# Bug Description
When the given file is used as input, `objdump` cannot finish execution within
600s.
Via debugging, I eventually confirm that the given input file triggered an
infinite loop in `objdump`.
```
(gdb) bt
#0 print_line (p=0x724f40, linenum=175019134) at ./objdump.c:2074
#1 0x004115f3 in dump_lines (p=0x724f40, start=175019135,
end=4294967295) at ./objdump.c:2093
#2 0x0041114a in show_line (abfd=0x707690, section=0x70a998,
addr_offset=258) at ./objdump.c:2292
#3 0x0040f1d2 in disassemble_bytes (inf=0x7fffdd58,
disassemble_fn=0x467200 , insns=true, data=0x721250
"\363\017\036\372\061\355I\211\321^H\211\342H\203\344\360PTI\307\300\300\030@",
start_offset=240, stop_offset=336, rel_offset=0,
relppp=0x7fffdc38, relppend=0x0) at ./objdump.c:3314
#4 0x0040c9b3 in disassemble_section (abfd=0x707690, section=0x70a998,
inf=0x7fffdd58) at ./objdump.c:4007
#5 0x004b2b37 in bfd_map_over_sections (abfd=0x707690,
operation=0x40bbb0 , user_storage=0x7fffdd58) at
section.c:1373
#6 0x00408d21 in disassemble_data (abfd=0x707690) at ./objdump.c:4151
#7 0x0040715e in dump_bfd (abfd=0x707690, is_mainfile=true) at
./objdump.c:5563
#8 0x00406a29 in display_object_bfd (abfd=0x707690) at
./objdump.c:5626
#9 0x004069e3 in display_any_bfd (file=0x707690, level=0) at
./objdump.c:5712
#10 0x0040624e in display_file (filename=0x7fffe3d4
"./objdump/hangs-600/hangs/000", target=0x0, last_file=true) at
./objdump.c:5733
#11 0x00404e43 in main (argc=3, argv=0x7fffe118) at
./objdump.c:6129
(gdb) f 1
#1 0x004115f3 in dump_lines (p=0x724f40, start=175019135,
end=4294967295) at ./objdump.c:2093
2093 print_line (p, start);
(gdb) list
2088{
2089 if (p->map == NULL)
2090return;
2091 while (start <= end)
2092{
2093 print_line (p, start);
2094 start++;
2095}
2096}
2097
(gdb) p end == -1
$1 = 1
```
As the type of `end` is u32, the looping could not terminate if `end`== -1 ==
0x (INTEGER OVERFLOW).
After backtracing the call stack, I found that the value of `end` comes from
`u32 linenumber` in function `show_line(...) :objdump.c:2106`, and the value of
`linenumber` is defined in function `bfd_find_nearest_line_discriminator(...,
&linenumber,...) :objdump.c:2155`. Although the value comes from from library
`bfd`, I think it is still necessary to check the value of the linenumber after
getting it.
`assert( linenumber != 0x && "linenumber cannot be -1.")`
# How to Reproduce
The aforementioned bug can be stably reproduced in version 2.39.50 (commit id
db0f0fcb.
1. Download the binutils-gdb source code with the [official
link](https://gitlab.com/libtiff/libtiff).
2. Build binutils-gdb with clang/clang++ (10.0.0-4ubuntu1),.
3. Execute objdump with the provided input files.
- eg: `/data/program/binutils-gdb/orig/bin/objdump -S `
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug binutils/29653] New: objcopy/strip: small input file induces large output file
https://sourceware.org/bugzilla/show_bug.cgi?id=29653
Bug ID: 29653
Summary: objcopy/strip: small input file induces large output
file
Product: binutils
Version: 2.40 (HEAD)
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: binutils
Assignee: unassigned at sourceware dot org
Reporter: chkunq at gmail dot com
Target Milestone: ---
Created attachment 14381
--> https://sourceware.org/bugzilla/attachment.cgi?id=14381&action=edit
a suspicious, small input file that makes objcopy/strip generate huge output
I don't know if this counts as a bug.
# Description
When I process a 274Byte input file using strip/objcopy, a file of 4294967520
Bytes (≈ 4GB) is generated as output.
The large output file is generated in the invocation of copy_object (ibfd,
obfd, input_arch)：objcopy.c:3905, and then a 10min checksum calculation occurs
in the invocation of bfd_close :objcopy.c:3905.
# Analysis
Through debugging, I found that the problem was with FileAlighment.
1. bfd libareads the file alighment data recorded in the section header of the
input file and uses it as the page_size of obfd (coffcode.h: 2984),
2. When executing coff_set_section_contents, an oversized page_size causes
abfd's iostream file position to be oversized after the
coff_compute_section_file_positions at coffcode.h: 4274. (coffcode.h: 3282,
3323),
3. Moreover, coff_compute_section_file_positions write a value at such a large
file position (coffcode.h: 3323),
4. Eventually, the invocation of bfd_seek in coffcode.h:4323 moves file
position indicator back, causing such a large file to be output directly.
I think this is very inappropriate, the 4G output file will easily fill up the
user's disk space, and will cause slow follow-up processing, e.g., such a large
file took me 10 minutes to calculate checksum (coff_compute_checksum:
coffcode.h:3378).
WHat's more, I also notice that past versions of binutils/bfd asserted that
page_size is not oversized, as follows.(When processing this file, the v2.36
version of strip will directly report an error and exit)
```
Strip: out-strip: page size is too large (0x)
Strip: out-strip []: file too big
```
However, in commit bc5baa9f13ff, this error check was removed (the type of
page_size is changed from s32 to u32).
```
- int page_size;
+ unsigned int page_size;
-
- /* PR 17512: file: 0ac816d3. */
- if (page_size < 0)
- {
- bfd_set_error (bfd_error_file_too_big);
- _bfd_error_handler
- /* xgettext:c-format */
- (_("%pB: page size is too large (0x%x)"), abfd, page_size);
- return false;
- }
```
So I don't know if this still counts as a bug, and if so, I can't tell if it's
a bug in the bfd library (after all, the relevant error check was deleted in
bfd) or a bug in binutils.
# How to Reproceduce
The aforementioned bug can be stably reproduced in version 2.39.50.20221003
(commit id e1fc9bcf).
1. Download the binutils-gdb source code with the [official
link](https://github.com/bminor/binutils-gdb).
2. Build binutils-gdb with clang/clang++ (10.0.0-4ubuntu1),.
3. Execute objdump with the provided input files.
- eg: `./strip -o /tmp/test `
- eg: `./objcopy -o /tmp/test`
Thanks & Best Regards.
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug binutils/31455] New: objcopy: invalid-free in bfd_init_section_compress_status
https://sourceware.org/bugzilla/show_bug.cgi?id=31455 Bug ID: 31455 Summary: objcopy: invalid-free in bfd_init_section_compress_status Product: binutils Version: 2.43 (HEAD) Status: UNCONFIRMED Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: chkunq at gmail dot com Target Milestone: --- Created attachment 15387 --> https://sourceware.org/bugzilla/attachment.cgi?id=15387&action=edit A zip archive containing the input files to trigger the bug Dear All, This bug was found on Ubuntu 20.04 64-bit & binutils was checked out from main repository at git://sourceware.org/git/binutils-gdb.git. Its commit is 5b95198e2e40b0301d37d989edc344a334c26b12 (Thu, 7 Mar 2024 00:00:53). binutils was built with ASAN using clang-14. The configure command was: CC=clang CFLAGS="-DFORTIFY_SOURCE -fstack-protector-all -fsanitize=address -fno-omit-frame-pointer -g -Wno-error" ../configure --disable-shared --disable-gdb --disable-libdecnumber --disable-readline --disable-sim To reproduce: Download and unzip the attached zip archive, and get POCs objcopy --compress-debug-sections [poc_file] /dev/null ASAN says: ==953211==ERROR: AddressSanitizer: attempting free on address which was not malloc()-ed: 0x621066f0 in thread T0 #0 0x3a19a2 in free /data/symccgo/bug/llvm-14-project/compiler-rt/lib/asan/asan_malloc_linux.cpp:52:3 #1 0x4a4c2c in bfd_init_section_compress_status /data/symccgo/bug/binutils/obj-asan/bfd/../../binutils-gdb/bfd/compress.c:1092:7 #2 0x5cb9eb in _bfd_elf_make_section_from_shdr /data/symccgo/bug/binutils/obj-asan/bfd/../../binutils-gdb/bfd/elf.c:1222:9 #3 0x5cefb1 in bfd_section_from_shdr /data/symccgo/bug/binutils/obj-asan/bfd/../../binutils-gdb/bfd/elf.c:3060:11 #4 0x764c93 in bfd_elf32_object_p /data/symccgo/bug/binutils/obj-asan/bfd/../../binutils-gdb/bfd/elfcode.h:880:7 #5 0x4afd2d in bfd_check_format_matches /data/symccgo/bug/binutils/obj-asan/bfd/../../binutils-gdb/bfd/format.c:437:17 #6 0x3e3f9d in copy_file /data/symccgo/bug/binutils/obj-asan/binutils/../../binutils-gdb/binutils/objcopy.c:3958:12 #7 0x3ed53c in copy_main /data/symccgo/bug/binutils/obj-asan/binutils/../../binutils-gdb/binutils/objcopy.c:6074:3 #8 0x3e12d9 in main /data/symccgo/bug/binutils/obj-asan/binutils/../../binutils-gdb/binutils/objcopy.c:6175:5 #9 0x7fb550494082 in __libc_start_main /build/glibc-SzIz7B/glibc-2.31/csu/../csu/libc-start.c:308:16 #10 0x31eeed in _start (/data/symccgo/bug/binutils/obj-asan/binutils/objcopy+0x31eeed) 0x621066f0 is located 496 bytes inside of 4064-byte region [0x62106500,0x621074e0) allocated by thread T0 here: #0 0x3a1c4e in malloc /data/symccgo/bug/llvm-14-project/compiler-rt/lib/asan/asan_malloc_linux.cpp:69:3 #1 0xa05b4b in _objalloc_alloc /data/symccgo/bug/binutils/obj-asan/libiberty/../../binutils-gdb/libiberty/objalloc.c:159:41 #2 0x4afd2d in bfd_check_format_matches /data/symccgo/bug/binutils/obj-asan/bfd/../../binutils-gdb/bfd/format.c:437:17 #3 0x3e3f9d in copy_file /data/symccgo/bug/binutils/obj-asan/binutils/../../binutils-gdb/binutils/objcopy.c:3958:12 #4 0x3ed53c in copy_main /data/symccgo/bug/binutils/obj-asan/binutils/../../binutils-gdb/binutils/objcopy.c:6074:3 #5 0x3e12d9 in main /data/symccgo/bug/binutils/obj-asan/binutils/../../binutils-gdb/binutils/objcopy.c:6175:5 #6 0x7fb550494082 in __libc_start_main /build/glibc-SzIz7B/glibc-2.31/csu/../csu/libc-start.c:308:16 SUMMARY: AddressSanitizer: bad-free /data/symccgo/bug/llvm-14-project/compiler-rt/lib/asan/asan_malloc_linux.cpp:52:3 in free ==2639543==ABORTING Moreover, objcopy (compiled by clang-14 -O0) crashes even without ASAN, as follows: free(): invalid pointer Aborted (core dumped) -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/31457] New: strip: SEGV in copy_archive
https://sourceware.org/bugzilla/show_bug.cgi?id=31457 Bug ID: 31457 Summary: strip: SEGV in copy_archive Product: binutils Version: 2.43 (HEAD) Status: UNCONFIRMED Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: chkunq at gmail dot com Target Milestone: --- Created attachment 15389 --> https://sourceware.org/bugzilla/attachment.cgi?id=15389&action=edit A zip archive containing the input files to trigger the bug Dear All, This bug was found on Ubuntu 20.04 64-bit & binutils was checked out from main repository at git://sourceware.org/git/binutils-gdb.git. Its commit is 5b95198e2e40b0301d37d989edc344a334c26b12 (Thu, 7 Mar 2024 00:00:53). binutils was built with ASAN using clang-14. The configure command was: CC=clang CFLAGS="-DFORTIFY_SOURCE -fstack-protector-all -fsanitize=address -fno-omit-frame-pointer -g -Wno-error" ../configure --disable-shared --disable-gdb --disable-libdecnumber --disable-readline --disable-sim To reproduce: Download and unzip the attached zip archive, and get POCs strip-new --strip-all -o /dev/null [poc_file] ASAN says: ==2468890==ERROR: AddressSanitizer: SEGV on unknown address 0x00f0 (pc 0x003e5972 bp 0x7ffd4c9d0d20 sp 0x7ffd4c9d09e0 T0) ==2468890==The signal is caused by a WRITE memory access. ==2468890==Hint: address points to the zero page. #0 0x3e5972 in copy_archive /data/symccgo/bug/binutils/obj-asan/binutils/../../binutils-gdb/binutils/objcopy.c:3798:8 #1 0x3e5972 in copy_file /data/symccgo/bug/binutils/obj-asan/binutils/../../binutils-gdb/binutils/objcopy.c:3956:7 #2 0x3e2513 in strip_main /data/symccgo/bug/binutils/obj-asan/binutils/../../binutils-gdb/binutils/objcopy.c:4973:7 #3 0x3e2513 in main /data/symccgo/bug/binutils/obj-asan/binutils/../../binutils-gdb/binutils/objcopy.c:6173:5 #4 0x7f32cec7f082 in __libc_start_main /build/glibc-SzIz7B/glibc-2.31/csu/../csu/libc-start.c:308:16 #5 0x31eeed in _start (/data/symccgo/bug/binutils/obj-asan/binutils/strip-new+0x31eeed) AddressSanitizer can not provide additional info. SUMMARY: AddressSanitizer: SEGV /data/symccgo/bug/binutils/obj-asan/binutils/../../binutils-gdb/binutils/objcopy.c:3798:8 in copy_archive ==2468890==ABORTING It's worth mentioning that this bug cannot be stably reproduced 100% in one attempt; it might require multiple attempts to replicate. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/31456] New: readelf: SEGV in read_leb128
https://sourceware.org/bugzilla/show_bug.cgi?id=31456 Bug ID: 31456 Summary: readelf: SEGV in read_leb128 Product: binutils Version: 2.43 (HEAD) Status: UNCONFIRMED Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: chkunq at gmail dot com Target Milestone: --- Created attachment 15388 --> https://sourceware.org/bugzilla/attachment.cgi?id=15388&action=edit A zip archive containing the input files to trigger the bug Dear All, This bug was found on Ubuntu 20.04 64-bit & binutils was checked out from main repository at git://sourceware.org/git/binutils-gdb.git. Its commit is 5b95198e2e40b0301d37d989edc344a334c26b12 (Thu, 7 Mar 2024 00:00:53). binutils was built with ASAN using clang-14. The configure command was: CC=clang CFLAGS="-DFORTIFY_SOURCE -fstack-protector-all -fsanitize=address -fno-omit-frame-pointer -g -Wno-error" ../configure --disable-shared --disable-gdb --disable-libdecnumber --disable-readline --disable-sim To reproduce: Download and unzip the attached zip archive, and get POCs readelf -w [poc_file] ASAN says: ==2829534==ERROR: AddressSanitizer: SEGV on unknown address 0x5021010101da (pc 0x0056213d bp 0x00782da0 sp 0x7ffdaff86770 T0) ==2829534==The signal is caused by a READ memory access. #0 0x56213d in read_leb128 /data/symccgo/bug/binutils/obj-asan/binutils/../../binutils-gdb/binutils/dwarf.c:289:28 #1 0x56213d in display_debug_names /data/symccgo/bug/binutils/obj-asan/binutils/../../binutils-gdb/binutils/dwarf.c:10759:8 #2 0x4be79d in display_debug_section /data/symccgo/bug/binutils/obj-asan/binutils/../../binutils-gdb/binutils/readelf.c:16950:18 #3 0x4be79d in process_section_contents /data/symccgo/bug/binutils/obj-asan/binutils/../../binutils-gdb/binutils/readelf.c:17046:10 #4 0x471fa3 in process_object /data/symccgo/bug/binutils/obj-asan/binutils/../../binutils-gdb/binutils/readelf.c:23160:9 #5 0x46b2d4 in process_file /data/symccgo/bug/binutils/obj-asan/binutils/../../binutils-gdb/binutils/readelf.c:23583:13 #6 0x46b2d4 in main /data/symccgo/bug/binutils/obj-asan/binutils/../../binutils-gdb/binutils/readelf.c:23654:11 #7 0x7ff763b87082 in __libc_start_main /build/glibc-SzIz7B/glibc-2.31/csu/../csu/libc-start.c:308:16 #8 0x37225d in _start (/data/symccgo/bug/binutils/obj-asan/binutils/readelf+0x37225d) AddressSanitizer can not provide additional info. SUMMARY: AddressSanitizer: SEGV /data/symccgo/bug/binutils/obj-asan/binutils/../../binutils-gdb/binutils/dwarf.c:289:28 in read_leb128 ==2829534==ABORTING -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/31457] strip: SEGV in copy_archive
https://sourceware.org/bugzilla/show_bug.cgi?id=31457 --- Comment #2 from Driller SE --- I'm also confused by this problem. I couldn't reproduce the problem 100% at each execution before. Even though I haven't updated the binutils for testing, this problem cannot be reproduced in my current environment. I guess the triggering of this problem may require a specific external environment (e.g. special memory state, special disk state, etc.) I'll try to figure out what's going on (if possible). -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/31457] strip: SEGV in copy_archive
https://sourceware.org/bugzilla/show_bug.cgi?id=31457 --- Comment #3 from Driller SE --- After a thorough reproduction process, I've come to the conclusion that this is a false positive caused by my oversight, for which I apologize for any inconvenience caused. Below is an explanation of the false positive, along with the relevant code: ```c output_element = bfd_openr (output_name, output_target); ptr = &output_element->archive_next; *ptr = NULL; ``` The false positive occurred because: During my testing of strip-new, I manually deleted the directory containing file`output_name` (before strip could automatically delete it), resulting in `bfd_openr` returning NULL to `output_element`, which then led to a SEGV at `*ptr = NULL`. Therefore, this problem would not occur under non-contrived circumstances (i.e., if the temporary directories were not manually deleted before strip automatically deletes them). -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/31457] strip: SEGV in copy_archive
https://sourceware.org/bugzilla/show_bug.cgi?id=31457 Driller SE changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |NOTABUG --- Comment #4 from Driller SE --- Mark this issue as NOTABUG -- You are receiving this mail because: You are on the CC list for the bug.
