Bug 25083 - unstrip tries to write out an enormous amount of data
Summary: unstrip tries to write out an enormous amount of data
Status: RESOLVED FIXED
Alias: None
Product: elfutils
Classification: Unclassified
Component: tools (show other bugs)
Version: unspecified
: P2 normal
Target Milestone: ---
Assignee: Mark Wielaard
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-10-08 15:00 UTC by leftcopy.chx
Modified: 2019-10-26 00:20 UTC (History)
2 users (show)

See Also:
Host:
Target:
Build:
Last reconfirmed: 2019-10-19 00:00:00


Attachments
hang input file and gdb backtrace (61.21 KB, application/x-bzip)
2019-10-08 15:00 UTC, leftcopy.chx
Details

Note You need to log in before you can comment on or make changes to this bug.
Description leftcopy.chx 2019-10-08 15:00:47 UTC
Created attachment 12034 [details]
hang input file and gdb backtrace

When executing `./eu-unstrip $FILE ./stripped -o /dev/null` (git commit 47780c9e), it may cause unexpected hangs against some crafted input file $FILE. 

When interrupted, the gdb backtrace is like:

#0  0x00007ffff763e6e7 in __libc_pwrite64 (fd=fd@entry=5, buf=buf@entry=0x7fffffff1b30, count=count@entry=4096, offset=offset@entry=4640862844) at ../sysdeps/unix/sysv/linux/pwrite64.c:29
#1  0x00007ffff7bcabd0 in pwrite_retry (off=4640862844, len=4096, buf=0x7fffffff1b30, fd=5) at ../lib/system.h:95
#2  fill (fd=<optimized out>, pos=4640862844, len=914482139140, fillbuf=fillbuf@entry=0x7fffffff1b30 "", filledp=filledp@entry=0x7fffffff1ae0) at elf32_updatefile.c:518
#3  0x00007ffff7bcbe86 in __elf64_updatefile (elf=elf@entry=0x555555765930, change_bo=change_bo@entry=0, shnum=shnum@entry=38) at elf32_updatefile.c:728
#4  0x00007ffff7bc7e99 in write_file (shnum=38, change_bo=0, size=919123089320, elf=0x555555765930) at elf_update.c:132
#5  elf_update (elf=0x555555765930, cmd=<optimized out>) at elf_update.c:231
#6  0x000055555555b64e in copy_elided_sections (unstripped=0x555555765930, stripped=<optimized out>, stripped_ehdr=<optimized out>, bias=<optimized out>) at unstrip.c:2074
#7  0x000055555555bb82 in handle_file (output_file=<optimized out>, create_dirs=<optimized out>, stripped=0x555555761950, stripped_ehdr=0x7fffffffc0c0, unstripped=0x555555763940)
    at unstrip.c:2162
#8  0x000055555555be97 in handle_explicit_files (output_file=0x7fffffffc9e1 "/tmp/test.file", create_dirs=<optimized out>, force=<optimized out>) at unstrip.c:2227
#9  0x0000555555557b4b in main (argc=<optimized out>, argv=0x7fffffffc428) at unstrip.c:2562

Relevant files are attached.
Comment 1 Mark Wielaard 2019-10-19 19:27:05 UTC
It doesn't really "hang", but tries to write out an enormous amount of data.

The issue is that both hangxx files have allocated section with a very large offset:

[ 9] .rela.dyn            NOBITS       00000000000015b8 d600000280 00002688 24 A
      5   0  8

[26] .bss                 NOBITS       0000000000212b80 e8ff012b60 00000490  0 WA     0   0 64

When writing out the new file eu-unstrip will dutifully try to place those sections at that exact offset in the file by putting "filler" (zeros) in the file till the offset is reached. That simply takes a very long time (or till the disk space runs out).
Comment 2 leftcopy.chx 2019-10-20 03:42:55 UTC
I see.
Is there a need to provide an upper bound for the offset?
Comment 3 Mark Wielaard 2019-10-20 10:18:15 UTC
(In reply to leftcopy.chx from comment #2)
> I see.
> Is there a need to provide an upper bound for the offset?

There is an offset for the upperbound that we might be able to detect. To be valid the offset in the original file should not be larger than the file size.   For allocated sections that is the original executable file size/
Comment 4 Mark Wielaard 2019-10-20 15:24:27 UTC
The following implements the sanity check and will prevent the hangs by generating an error if the section offset of an allocated section in the original file is too large when we have to preserve it:

diff --git a/src/unstrip.c b/src/unstrip.c
index fc878325..d9bafe5c 100644
--- a/src/unstrip.c
+++ b/src/unstrip.c
@@ -1388,6 +1388,17 @@ copy_elided_sections (Elf *unstripped, Elf *stripped,
     error (EXIT_FAILURE, 0, _("\
 more sections in stripped file than debug file -- arguments reversed?"));
 
+
+  /* Used as sanity check for allocated section offset, if the section
+     offset needs to be preserved.  We want to know the max size of the
+     ELF file, to check if any existing section offsets are OK.  */
+  int64_t max_off = -1;
+  if (stripped_ehdr->e_type != ET_REL)
+    {
+      elf_flagelf (stripped, ELF_C_SET, ELF_F_LAYOUT);
+      max_off = elf_update (stripped, ELF_C_NULL);
+    }
+
   /* Cache the stripped file's section details.  */
   struct section sections[stripped_shnum - 1];
   Elf_Scn *scn = NULL;
@@ -1675,6 +1686,11 @@ more sections in stripped file than debug file -- arguments reversed?"));
        /* Preserve the file layout of the allocated sections.  */
        if (stripped_ehdr->e_type != ET_REL && (shdr_mem.sh_flags & SHF_ALLOC))
          {
+           if (max_off > 0 && sec->shdr.sh_offset > (Elf64_Off) max_off)
+               error (EXIT_FAILURE, 0,
+                      "allocated section offset too large [%zd] %" PRIx64,
+                      elf_ndxscn (sec->scn), sec->shdr.sh_offset);
+
            shdr_mem.sh_offset = sec->shdr.sh_offset;
            placed[elf_ndxscn (sec->outscn) - 1] = true;
Comment 5 Mark Wielaard 2019-10-26 00:20:55 UTC
commit 9d3003f6b0baa94a53013fbefb4f6542bc532a6c (HEAD -> master)
Author: Mark Wielaard <mark@klomp.org>
Date:   Sun Oct 20 17:26:29 2019 +0200

    unstrip: Add sanity check for bogus sh_offset of allocated sections.
    
    unstrip tries to preserve any allocated section offset in an
    executable or shared library. If the offset is extremely large that
    would cause the disk to fill up because we will write out a file with
    lots of padding to put the section contents at that particular
    offset. Add a sanity check that makes sure we just error out if there
    is such a bogus offset by checking that no offset is larger than the
    original ELF file size.
    
    https://sourceware.org/bugzilla/show_bug.cgi?id=25083
    
    Signed-off-by: Mark Wielaard <mark@klomp.org>