[Bug libelf/25077] AddressSanitizer: heap-buffer-overflow at libelf/elf32_updatefile.c:772

[mark at klomp dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=25077

Mark Wielaard  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-10-19
 CC||mark at klomp dot org
 Ever confirmed|0   |1

--- Comment #1 from Mark Wielaard  ---
Replicated under valgrind:

$ valgrind -q eu-unstrip hbo_libelf/hbo__elf32_updatefile.c:772_1
hbo_libelf/stripped -o /tmp/foobar
==25850== Syscall param pwrite64(buf) points to unaddressable byte(s)
==25850==at 0x57A80D3: __pwrite_nocancel (syscall-template.S:81)
==25850==by 0x4E45E37: UnknownInlinedFun (system.h:95)
==25850==by 0x4E45E37: __elf64_updatefile (elf32_updatefile.c:795)
==25850==by 0x4E42250: write_file (elf_update.c:132)
==25850==by 0x4E42250: elf_update (elf_update.c:231)
==25850==by 0x406840: copy_elided_sections (unstrip.c:2070)
==25850==by 0x4078B3: handle_file (unstrip.c:2158)
==25850==by 0x407B8B: handle_explicit_files (unstrip.c:2223)
==25850==by 0x4029DD: main (unstrip.c:2558)
==25850==  Address 0x632b8c6 is 0 bytes after a block of size 470 alloc'd
==25850==at 0x4C2BF79: calloc (vg_replace_malloc.c:762)
==25850==by 0x408028: xcalloc (xmalloc.c:63)
==25850==by 0x403FD6: adjust_relocs.isra.14 (unstrip.c:565)
==25850==by 0x406CC6: copy_elided_sections (unstrip.c:1956)
==25850==by 0x4078B3: handle_file (unstrip.c:2158)
==25850==by 0x407B8B: handle_explicit_files (unstrip.c:2223)
==25850==by 0x4029DD: main (unstrip.c:2558)
==25850== 
eu-unstrip: cannot write output file: cannot write data to file

The issue is simply that if the sh_entsize of the symver section was bogus
(bigger than necessary) then some bogus data would be written out (except that
then fails as can be seen by the error message).

The solution is simply to use the actual symver data size:

diff --git a/src/unstrip.c b/src/unstrip.c
index fc878325..5531a02d 100644
--- a/src/unstrip.c
+++ b/src/unstrip.c
@@ -572,7 +572,7 @@ adjust_relocs (Elf_Scn *outscn, Elf_Scn *inscn, const
GElf_Shdr *shdr,

record_new_data (versym);
data->d_buf = versym;
-   data->d_size = nent * shdr->sh_entsize;
+   data->d_size = nent * sizeof versym[0];
elf_flagdata (data, ELF_C_SET, ELF_F_DIRTY);
update_sh_size (outscn, data);
   }

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug libelf/25083] Unexpected hangs at elf32_updatefile.c:518

[mark at klomp dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=25083

Mark Wielaard  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-10-19
 CC||mark at klomp dot org
 Ever confirmed|0   |1

--- Comment #1 from Mark Wielaard  ---
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.dynNOBITS   15b8 d60280 2688 24
A
  5   0  8

[26] .bss NOBITS   00212b80 e8ff012b60 0490  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).

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug libelf/25083] Unexpected hangs at elf32_updatefile.c:518

[leftcopy.chx at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=25083

--- Comment #2 from leftcopy.chx at gmail dot com ---
I see.
Is there a need to provide an upper bound for the offset?

-- 
You are receiving this mail because:
You are on the CC list for the bug.