public inbox for elfutils@sourceware.org
 help / color / mirror / Atom feed
From: Mark Wielaard <mark@klomp.org>
To: Daniel Xu <dxu@dxuuu.xyz>
Cc: elfutils-devel@sourceware.org
Subject: Re: Noop round trip through elf_update() causes segfaults
Date: Sat, 30 Dec 2023 18:41:01 +0100	[thread overview]
Message-ID: <20231230174101.GC9034@gnu.wildebeest.org> (raw)
In-Reply-To: <43591825-18a6-4dbd-b27c-fa96d150dc31@app.fastmail.com>

Hi Daniel,

On Wed, Dec 27, 2023 at 08:40:09PM -0600, Daniel Xu wrote:
> I was working on code that adds an ELF section containing custom
> metadata to ELF binaries when I started getting odd segfaults
> in the added-to binary.
> 
> I've managed to create a minimal reproducer with a couple interesting
> discoveries. The reproducer is available here:
> 
>         https://github.com/danobi/elf-segfault
> 
> Basically it does a noop round trip between elf_begin() and elf_update().
> But the resulting binary, when run, outputs:
> 
>         $ ./testprog_copy
>         fish: Job 1, './testprog_copy' terminated by signal SIGSEGV (Address boundary error)
> 
> Furthermore, I built and ran tests/addsections.c [0] against my testbinary
> and I still get:
> 
>         $ ./testprog_copy_elfutils
>         fish: Job 1, './testprog_copy_elfutils' terminated by signal SIGSEGV (Address boundary error)
>  
> I've also tried linking against upstream libelf built from source
> with the same results.
> 
> This leads me to believe I'm doing something very wrong or
> I'm hitting a bug.

You aren't doing something very wrong, but libelf does something you
aren't expecting. When you are calling elf_update () it will rearrange
the elf sections making sure there are no unnecessary gaps between the
sections in the file, that alignment is correct, etc.

libelf only cares about the section headers. It doesn't know/care
about the program headers. The program headers describe how the
segments have to be loaded at runtime. Since some data has moved
around the program data isn't loaded correctly anymore which causes
the crash.

To prevent libelf from doing this, and take responsibility of how the
sections are layed out yourself you have to call:

  elf_flagelf (elf, ELF_C_SET, ELF_F_LAYOUT);

Before calling elf_update. Note that in that case you are responsible
for setting/updating the sh_offset fields of the Shdrs yourself.

See for example the elfutils src/elfcompress.c program to see what it
does in case the Elf file has program headers.

Hope that helps,

Mark

  reply	other threads:[~2023-12-30 17:41 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-12-28  2:40 Daniel Xu
2023-12-30 17:41 ` Mark Wielaard [this message]
2023-12-31  5:16   ` Daniel Xu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20231230174101.GC9034@gnu.wildebeest.org \
    --to=mark@klomp.org \
    --cc=dxu@dxuuu.xyz \
    --cc=elfutils-devel@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).