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 (0xffffffff)
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 <input-file>`
- eg: `./objcopy -o <input-file> /tmp/test`
Thanks & Best Regards.
--
You are receiving this mail because:
You are on the CC list for the bug.
