From: Kees Cook <keescook@chromium.org>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Jan Bujak <j@exia.io>, Pedro Falcato <pedro.falcato@gmail.com>,
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: Tue, 27 Feb 2024 09:22:35 -0800 [thread overview]
Message-ID: <202402270911.961702D7D6@keescook> (raw)
In-Reply-To: <878r35rkc4.fsf@email.froward.int.ebiederm.org>
On Tue, Feb 27, 2024 at 09:35:39AM -0600, Eric W. Biederman wrote:
> Kees Cook <keescook@chromium.org> writes:
>
> > On Tue, Jan 23, 2024 at 12:23:27AM +0900, Jan Bujak wrote:
> >> On 1/22/24 23:54, Pedro Falcato wrote:
> >> > 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.
> >> >
> >>
> >> I wrote the linker script myself from scratch.
> >
> > Do you still need this addressed, or have you been able to adjust the
> > linker script? (I ask to try to assess the priority of needing to fix
> > this behavior change...)
>
> Kees, I haven't had a chance to test this yet but it occurred to me
> that there is an easy way to handle this. In our in-memory copy
> of the elf program headers we can just merge the two segments
> together.
>
> I believe the diff below accomplishes that, and should fix issue.
>
> Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
>
> diff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c
> index 5397b552fbeb..01df7dd1f3b4 100644
> --- a/fs/binfmt_elf.c
> +++ b/fs/binfmt_elf.c
> @@ -924,6 +926,31 @@ static int load_elf_binary(struct linux_binprm *bprm)
> elf_ppnt = elf_phdata;
> for (i = 0; i < elf_ex->e_phnum; i++, elf_ppnt++)
> switch (elf_ppnt->p_type) {
> + case PT_LOAD:
> + {
> + /*
> + * Historically linux ignored all but the
> + * final .bss segment. Now that linux honors
> + * all .bss segments, a .bss segment that
> + * logically is not overlapping but is
> + * overlapping when it's edges are rounded up
> + * to page size causes programs to fail.
> + *
> + * Handle that case by merging .bss segments
> + * into the segment they follow.
> + */
> + if (((i + 1) >= elf_ex->e_phnum) ||
> + (elf_ppnt[1].p_type != PT_LOAD) ||
> + (elf_ppnt[1].p_filesz != 0))
> + continue;
> + unsigned long end =
> + elf_ppnt[0].p_vaddr + elf_ppnt[0].p_memsz;
> + if (elf_ppnt[1].p_vaddr != end)
> + continue;
> + elf_ppnt[0].p_memsz += elf_ppnt[1].p_memsz;
> + elf_ppnt[1].p_type = PT_NULL;
> + break;
> + }
> case PT_GNU_STACK:
> if (elf_ppnt->p_flags & PF_X)
> executable_stack = EXSTACK_ENABLE_X;
I don't think this is safe -- it isn't looking at flags, etc. e.g.,
something like this could break:
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
LOAD 0x003000 0x12000 0x12000 0x001000 0x001000 R E 0x1000
LOAD 0x004000 0x13000 0x13000 0x000000 0x001000 RW 0x1000
Hmm
--
Kees Cook
next prev parent reply other threads:[~2024-02-27 17:22 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-22 12:01 Recent-ish changes in binfmt_elf made my program segfault Jan Bujak
2024-01-22 14:54 ` Pedro Falcato
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 [this message]
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=202402270911.961702D7D6@keescook \
--to=keescook@chromium.org \
--cc=brauner@kernel.org \
--cc=ebiederm@xmission.com \
--cc=j@exia.io \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=pedro.falcato@gmail.com \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.