From: Pedro Falcato <pedro.falcato@gmail.com>
To: Jan Bujak <j@exia.io>
Cc: ebiederm@xmission.com, keescook@chromium.org, linux-mm@kvack.org,
linux-kernel@vger.kernel.org, viro@zeniv.linux.org.uk,
brauner@kernel.org, linux-fsdevel@vger.kernel.org
Subject: Re: Recent-ish changes in binfmt_elf made my program segfault
Date: Mon, 22 Jan 2024 14:54:52 +0000 [thread overview]
Message-ID: <CAKbZUD2=W0Ng=rFVDn3UwSxtGQ5c13tRwkpqm54pPCJO0BraWA@mail.gmail.com> (raw)
In-Reply-To: <c7209e19-89c4-446a-b364-83100e30cc00@exia.io>
On Mon, Jan 22, 2024 at 12:16 PM Jan Bujak <j@exia.io> wrote:
>
> Hi.
>
> I recently updated my kernel and one of my programs started segfaulting.
>
> The issue seems to be related to how the kernel interprets PT_LOAD headers;
> consider the following program headers (from 'readelf' of my reproduction):
>
> Program Headers:
> Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
> LOAD 0x001000 0x10000 0x10000 0x000010 0x000010 R 0x1000
> LOAD 0x002000 0x11000 0x11000 0x000010 0x000010 RW 0x1000
> LOAD 0x002010 0x11010 0x11010 0x000000 0x000004 RW 0x1000
> LOAD 0x003000 0x12000 0x12000 0x0000d2 0x0000d2 R E 0x1000
> LOAD 0x004000 0x20000 0x20000 0x000004 0x000004 RW 0x1000
>
> Old kernels load this ELF file in the following way ('/proc/self/maps'):
>
> 00010000-00011000 r--p 00001000 00:02 131 ./bug-reproduction
> 00011000-00012000 rw-p 00002000 00:02 131 ./bug-reproduction
> 00012000-00013000 r-xp 00003000 00:02 131 ./bug-reproduction
> 00020000-00021000 rw-p 00004000 00:02 131 ./bug-reproduction
>
> And new kernels do it like this:
>
> 00010000-00011000 r--p 00001000 00:02 131 ./bug-reproduction
> 00011000-00012000 rw-p 00000000 00:00 0
> 00012000-00013000 r-xp 00003000 00:02 131 ./bug-reproduction
> 00020000-00021000 rw-p 00004000 00:02 131 ./bug-reproduction
>
> That map between 0x11000 and 0x12000 is the program's '.data' and '.bss'
> sections to which it tries to write to, and since the kernel doesn't map
> them anymore it crashes.
>
> I bisected the issue to the following commit:
>
> commit 585a018627b4d7ed37387211f667916840b5c5ea
> Author: Eric W. Biederman <ebiederm@xmission.com>
> Date: Thu Sep 28 20:24:29 2023 -0700
>
> binfmt_elf: Support segments with 0 filesz and misaligned starts
>
> I can confirm that with this commit the issue reproduces, and with it
> reverted it doesn't.
>
> I have prepared a minimal reproduction of the problem available here,
> along with all of the scripts I used for bisecting:
>
> https://github.com/koute/linux-elf-loading-bug
>
> You can either compile it from source (requires Rust and LLD), or there's
> a prebuilt binary in 'bin/bug-reproduction` which you can run. (It's tiny,
> so you can easily check with 'objdump -d' that it isn't malicious).
>
> On old kernels this will run fine, and on new kernels it will segfault.
Hi!
Where did you get that linker script?
FWIW, I catched this possible issue in review, and this was already
discussed (see my email and Eric's reply):
https://lore.kernel.org/all/CAKbZUD3E2if8Sncy+M2YKncc_Zh08-86W6U5wR0ZMazShxbHHA@mail.gmail.com/
This was my original testcase
(https://github.com/heatd/elf-bug-questionmark), which convinced the
loader to map .data over a cleared .bss. Your bug seems similar, but
does the inverse: maps .bss over .data.
--
Pedro
next prev parent reply other threads:[~2024-01-22 14:55 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-22 12:01 Jan Bujak
2024-01-22 14:54 ` Pedro Falcato [this message]
2024-01-22 15:23 ` Jan Bujak
2024-02-27 2:23 ` Kees Cook
2024-02-27 15:35 ` Eric W. Biederman
2024-02-27 17:22 ` Kees Cook
2024-02-27 20:59 ` Eric W. Biederman
2024-01-22 16:43 ` Eric W. Biederman
2024-01-22 20:48 ` Kees Cook
2024-01-22 21:01 ` Eric W. Biederman
2024-01-22 22:12 ` Kees Cook
2024-02-01 10:47 ` Linux regression tracking (Thorsten Leemhuis)
2024-02-04 23:27 ` Kees Cook
2024-02-26 5:54 ` Linux regression tracking (Thorsten Leemhuis)
2024-03-25 15:26 ` Linux regression tracking (Thorsten Leemhuis)
2024-03-25 16:56 ` Kees Cook
2024-03-25 17:08 ` Thorsten Leemhuis
2024-01-24 6:59 ` Linux regression tracking #adding (Thorsten Leemhuis)
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='CAKbZUD2=W0Ng=rFVDn3UwSxtGQ5c13tRwkpqm54pPCJO0BraWA@mail.gmail.com' \
--to=pedro.falcato@gmail.com \
--cc=brauner@kernel.org \
--cc=ebiederm@xmission.com \
--cc=j@exia.io \
--cc=keescook@chromium.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=viro@zeniv.linux.org.uk \
/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