public inbox for debugedit@sourceware.org
 help / color / mirror / Atom feed
* [Bug debugedit/28408] New: debugedit segfaults while changing binutils' build-id
@ 2021-10-01 16:33 alexey.brodkin at gmail dot com
  2021-10-05 11:04 ` [Bug debugedit/28408] " mark at klomp dot org
  2021-10-11 14:17 ` mark at klomp dot org
  0 siblings, 2 replies; 3+ messages in thread
From: alexey.brodkin at gmail dot com @ 2021-10-01 16:33 UTC (permalink / raw)
  To: debugedit

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

            Bug ID: 28408
           Summary: debugedit segfaults while changing binutils' build-id
           Product: debugedit
           Version: unspecified
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: debugedit
          Assignee: unassigned at sourceware dot org
          Reporter: alexey.brodkin at gmail dot com
                CC: debugedit at sourceware dot org
  Target Milestone: ---

Created attachment 13694
  --> https://sourceware.org/bugzilla/attachment.cgi?id=13694&action=edit
Cross-compiled m68k library

Initially seen on cross-compilation of Binutils in Debian and then 
reported here https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=995195.

In a nutshell "debugedit" segfaults on attempt to run the following command on
x86_64 host against a binary built for a big-endian architecture in this
example it's "libbfd-2.37-system.so" (attached) cross-compiled for m68k:
------------------------->8-----------------------
$ debugedit --build-id --build-id-seed=x libbfd-2.37-system.so
Segmentation fault
------------------------->8-----------------------

That's what we with GDB:
------------------------->8-----------------------
$ gdb --args ./debugedit --build-id --build-id-seed=x libbfd-2.37-system.so
(gdb) r
Starting program: .../debugedit/debugedit --build-id --build-id-seed=x
libbfd-2.37-system.so
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault.
__memmove_avx_unaligned_erms () at
../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:365
365     ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S: No such file
or directory.
(gdb) bt
#0  __memmove_avx_unaligned_erms () at
../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:365
#1  0x000055555555fea8 in memcpy (__len=83, __src=0x0, __dest=0x7fffffffe02d)
at /usr/include/x86_64-linux-gnu/bits/string_fortified.h:34
#2  sha1_process_bytes (buffer=0x0, len=452, ctx=0x7fffffffdfe0) at
tools/sha1.c:210
#3  0x0000555555557d43 in handle_build_id (build_id_size=<optimized out>,
build_id_offset=16, build_id=0x555555566448, dso=0x5555555678d0) at
tools/debugedit.c:3285
#4  main (argc=<optimized out>, argv=<optimized out>) at tools/debugedit.c:3638
------------------------->8-----------------------

If we look a bit deeper we may notice that while processing ".bss" section
we're   not seeing "u.shdr.sh_type == SHT_NOBITS" here
https://sourceware.org/git/?p=debugedit.git;a=blob;f=tools/debugedit.c;h=668777ad47d9b51d0cd118b7d91281963dafa6be;hb=HEAD#l3276.
Instead we see "u.shdr.sh_type = 0x08000000", which is exactly byte-swapped 0x8
which stands for SHT_NOBITS.

And since that check doesn't catch NOBITS section we later segfault trying to
process some other garbage.

That said there's something wrong with interpretation of a foreign endianess.


And this could be reproduced with both debugedit & elfutils built from today's
"master" barnches.

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

^ permalink raw reply	[flat|nested] 3+ messages in thread

* [Bug debugedit/28408] debugedit segfaults while changing binutils' build-id
  2021-10-01 16:33 [Bug debugedit/28408] New: debugedit segfaults while changing binutils' build-id alexey.brodkin at gmail dot com
@ 2021-10-05 11:04 ` mark at klomp dot org
  2021-10-11 14:17 ` mark at klomp dot org
  1 sibling, 0 replies; 3+ messages in thread
From: mark at klomp dot org @ 2021-10-05 11:04 UTC (permalink / raw)
  To: debugedit

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

Mark Wielaard <mark at klomp dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2021-10-05
             Status|UNCONFIRMED                 |ASSIGNED
                 CC|                            |mark at klomp dot org
     Ever confirmed|0                           |1

--- Comment #1 from Mark Wielaard <mark at klomp dot org> ---
Thanks for the report and the reproducer.
Your analysis is correct.

The problem is summarized in this comment just before the problematic code:

  /* Slurp the relevant header bits and section contents and feed them
     into the hash function.  The only bits we ignore are the offset
     fields in ehdr and shdrs, since the semantically identical ELF file
     could be written differently if it doesn't change the phdr layout.
     We always use the GElf (i.e. Elf64) formats for the bits to hash
     since it is convenient.  It doesn't matter whether this is an Elf32
     or Elf64 object, only that we are consistent in what bits feed the
     hash so it comes out the same for the same file contents.  */

So we mangled the actual data structure, but then check it as if it hasn't been
flipped around anyway when checking for NOBITS. The fix is to use the original
data/shdr to check for NOBITS:

diff --git a/tools/debugedit.c b/tools/debugedit.c
index 668777a..3f1e830 100644
--- a/tools/debugedit.c
+++ b/tools/debugedit.c
@@ -3273,7 +3273,7 @@ handle_build_id (DSO *dso, Elf_Data *build_id,
          else
            sha1_process_bytes (x.d_buf, x.d_size, &sha1_ctx);

-         if (u.shdr.sh_type != SHT_NOBITS)
+         if (dso->shdr[i].sh_type != SHT_NOBITS)
            {
              Elf_Data *d = elf_getdata (dso->scn[i], NULL);
              if (d == NULL)

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

^ permalink raw reply	[flat|nested] 3+ messages in thread

* [Bug debugedit/28408] debugedit segfaults while changing binutils' build-id
  2021-10-01 16:33 [Bug debugedit/28408] New: debugedit segfaults while changing binutils' build-id alexey.brodkin at gmail dot com
  2021-10-05 11:04 ` [Bug debugedit/28408] " mark at klomp dot org
@ 2021-10-11 14:17 ` mark at klomp dot org
  1 sibling, 0 replies; 3+ messages in thread
From: mark at klomp dot org @ 2021-10-11 14:17 UTC (permalink / raw)
  To: debugedit

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

Mark Wielaard <mark at klomp dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|---                         |FIXED

--- Comment #2 from Mark Wielaard <mark at klomp dot org> ---
commit f62fdfc7e8ddb9887f91a021636a4b430c76ec05
Author: Mark Wielaard <mark@klomp.org>
Date:   Mon Oct 11 13:57:15 2021 +0200

    debugedit: Use original shdr sh_type to check for NOBITS

            * tools/debugedit.c (handle_build_id): Check SHT_NOBITS
            against dso->shdr[i].sh_type.

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

    Reported-by: Alexey Brodkin <alexey.brodkin@gmail.com>
    Signed-off-by: Mark Wielaard <mark@klomp.org>

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

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2021-10-11 14:17 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-10-01 16:33 [Bug debugedit/28408] New: debugedit segfaults while changing binutils' build-id alexey.brodkin at gmail dot com
2021-10-05 11:04 ` [Bug debugedit/28408] " mark at klomp dot org
2021-10-11 14:17 ` mark at klomp dot org

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).