[Bug binutils/29653] New: objcopy/strip: small input file induces large output file

[chkunq at gmail dot com]

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.