[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.
Issue 52052 in oss-fuzz: binutils:fuzz_addr2line: Out-of-memory in fuzz_addr2line
Updates: Labels: -restrict-view-commit Comment #3 on issue 52052 by sheriffbot: binutils:fuzz_addr2line: Out-of-memory in fuzz_addr2line https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=52052#c3 This bug has been fixed. It has been opened to the public. - Your friendly Sheriffbot -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment.
[Bug ld/29654] New: ld: add -w to suppress warnings
https://sourceware.org/bugzilla/show_bug.cgi?id=29654 Bug ID: 29654 Summary: ld: add -w to suppress warnings Product: binutils Version: 2.40 (HEAD) Status: NEW Severity: normal Priority: P2 Component: ld Assignee: unassigned at sourceware dot org Reporter: i at maskray dot me Target Milestone: --- Apple ld64 and llvm-project ld64.lld support -w to suppress warnings. -w was picked likely because compiler drivers use -w to suppress warnings. I think -w mildly benefits GNU ld/gold as well. With --noinhibit-exec, we downgrade errors to warnings. When analyzing a large executable with relocation overflow issues, we may use --noinhibit-exec --emit-relocs to get relocations and an output file despite relocation overflow issues. Since we know the output otherwise does not link, the warnings are not useful. If we have -w, we can add -w to not see the unuseful warnings. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gprofng/29107] gas testsuite parallel jobs fail (gprofng?)
https://sourceware.org/bugzilla/show_bug.cgi?id=29107
--- Comment #5 from Vladimir Mezentsev
---
This is a side-effect of our fake installation for gprofng testing:
>> # Make a temporary install dir to run gprofng from, and point at it
>> remote_exec host "sh -c \"rm -rf tmpdir; mkdir -p tmpdir; $MAKE -C ..
>> install-gprofng
>> program_transform_name= DESTDIR=`pwd`/tmpdir/root\""
I will fix this and will not run '$MAKE install-gprofng'.
But why is libopcodes.la rebuilt when I run `make install` ?
To reproduce:
% ../binutils-gdb.git/configure --prefix=`pwd`/INSTALL --with-system-zlib
--enable-shared
--disable-{gdb,gdbserver,libbacktrace,libdecnumber,readline,sim}
% make -j 100
% make install
...
make[4]: Nothing to be done for 'install-exec-am'.
/bin/mkdir -p '/data2/vmezents/bld/INSTALL/include'
/bin/install -c -m 644 ../../binutils-gdb.git/opcodes/../include/dis-asm.h
'/data2/vmezents/bld/INSTALL/include'
/bin/mkdir -p '/data2/vmezents/bld/INSTALL/lib'
/bin/sh ./libtool --mode=install /bin/install -c libopcodes.la
'/data2/vmezents/bld/INSTALL/lib'
libtool: install: warning: relinking `libopcodes.la'
^^
| Why ? There were no changes.
libtool: install: (cd /data2/vmezents/bld/opcodes; /bin/sh
/data2/vmezents/bld/opcodes/libtool --silent --tag CC --mode=relink gcc
-W -Wall -Wstrict-prototypes -Wmissing-prototypes -Wshadow
-Wstack-usage=262144 -Werror -g -O2 -release 2.39.50.20221006
-o libopcodes.la
-rpath /data2/vmezents/bld/INSTALL/lib dis-buf.lo disassemble.lo
dis-init.lo i386-dis.lo i386-opc.lo ../bfd/libbfd.la
-L/data2/vmezents/bld/opcodes/../libiberty/pic -liberty
-Wl,-lc,--as-needed,-lm,--no-as-needed )
We see libopcodes.la was rebuilt.
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug gprofng/29579] ld: .libs/libgp_collector_la-mmaptrace.o (symbol from plugin): in function `dlclose': on i586
https://sourceware.org/bugzilla/show_bug.cgi?id=29579 --- Comment #6 from Vladimir Mezentsev --- Are your build problems resolved ? -- You are receiving this mail because: You are on the CC list for the bug.
