From: Pedro Falcato <pedro.falcato@gmail.com>
To: "Thomas Weißschuh" <linux@weissschuh.net>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>,
Christian Brauner <brauner@kernel.org>,
Eric Biederman <ebiederm@xmission.com>,
Kees Cook <keescook@chromium.org>,
Mark Brown <broonie@kernel.org>, Willy Tarreau <w@1wt.eu>,
linux-fsdevel@vger.kernel.org, linux-mm@kvack.org,
linux-kernel@vger.kernel.org, Sebastian Ott <sebott@redhat.com>,
stable@vger.kernel.org
Subject: Re: [PATCH RFC] binfmt_elf: fully allocate bss pages
Date: Fri, 15 Sep 2023 23:15:05 +0100 [thread overview]
Message-ID: <CAKbZUD2r7e673gDF8un8vw4GAVgMLG=Lk7F0-HfK5Mz59Sxzxw@mail.gmail.com> (raw)
In-Reply-To: <20230914-bss-alloc-v1-1-78de67d2c6dd@weissschuh.net>
On Fri, Sep 15, 2023 at 4:54 AM Thomas Weißschuh <linux@weissschuh.net> wrote:
>
> When allocating the pages for bss the start address needs to be rounded
> down instead of up.
> Otherwise the start of the bss segment may be unmapped.
>
> The was reported to happen on Aarch64:
>
> Memory allocated by set_brk():
> Before: start=0x420000 end=0x420000
> After: start=0x41f000 end=0x420000
>
> The triggering binary looks like this:
>
> Elf file type is EXEC (Executable file)
> Entry point 0x400144
> There are 4 program headers, starting at offset 64
>
> Program Headers:
> Type Offset VirtAddr PhysAddr
> FileSiz MemSiz Flags Align
> LOAD 0x0000000000000000 0x0000000000400000 0x0000000000400000
> 0x0000000000000178 0x0000000000000178 R E 0x10000
> LOAD 0x000000000000ffe8 0x000000000041ffe8 0x000000000041ffe8
> 0x0000000000000000 0x0000000000000008 RW 0x10000
> NOTE 0x0000000000000120 0x0000000000400120 0x0000000000400120
> 0x0000000000000024 0x0000000000000024 R 0x4
> GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000
> 0x0000000000000000 0x0000000000000000 RW 0x10
>
> Section to Segment mapping:
> Segment Sections...
> 00 .note.gnu.build-id .text .eh_frame
> 01 .bss
> 02 .note.gnu.build-id
> 03
>
> Reported-by: Sebastian Ott <sebott@redhat.com>
> Closes: https://lore.kernel.org/lkml/5d49767a-fbdc-fbe7-5fb2-d99ece3168cb@redhat.com/
> Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
> Cc: stable@vger.kernel.org
> Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
> ---
>
> I'm not really familiar with the ELF loading process, so putting this
> out as RFC.
>
> A example binary compiled with aarch64-linux-gnu-gcc 13.2.0 is available
> at https://test.t-8ch.de/binfmt-bss-repro.bin
> ---
> fs/binfmt_elf.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c
> index 7b3d2d491407..4008a57d388b 100644
> --- a/fs/binfmt_elf.c
> +++ b/fs/binfmt_elf.c
> @@ -112,7 +112,7 @@ static struct linux_binfmt elf_format = {
>
> static int set_brk(unsigned long start, unsigned long end, int prot)
> {
> - start = ELF_PAGEALIGN(start);
> + start = ELF_PAGESTART(start);
> end = ELF_PAGEALIGN(end);
> if (end > start) {
> /*
I don't see how this change can be correct. set_brk takes the start of
.bss as the start, so doing ELF_PAGESTART(start) will give you what
may very well be another ELF segment. In the common case, you'd map an
anonymous page on top of someone's .data, which will misload the ELF.
The current logic looks OK to me (gosh this code would ideally take a
good refactoring...). I still can't quite tell how padzero() (in the
original report) is -EFAULTing though.
--
Pedro
next prev parent reply other threads:[~2023-09-15 22:15 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-14 15:59 Thomas Weißschuh
2023-09-14 19:49 ` Eric W. Biederman
2023-09-14 22:18 ` Thomas Weißschuh
2023-09-15 19:35 ` Sebastian Ott
2023-09-15 22:15 ` Pedro Falcato [this message]
2023-09-15 22:41 ` Thomas Weißschuh
2023-09-18 14:11 ` kernel test robot
2023-09-21 10:36 ` Sebastian Ott
2023-09-25 0:50 ` Eric W. Biederman
2023-09-25 9:20 ` Sebastian Ott
2023-09-25 9:50 ` Eric W. Biederman
2023-09-25 12:59 ` [PATCH] binfmt_elf: Support segments with 0 filesz and misaligned starts Eric W. Biederman
2023-09-25 15:27 ` Sebastian Ott
2023-09-25 17:06 ` Kees Cook
2023-09-26 3:27 ` Eric W. Biederman
2023-09-27 2:34 ` Kees Cook
2023-09-26 13:49 ` Dan Carpenter
2023-09-26 14:42 ` [PATCH v2] " Eric W. Biederman
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='CAKbZUD2r7e673gDF8un8vw4GAVgMLG=Lk7F0-HfK5Mz59Sxzxw@mail.gmail.com' \
--to=pedro.falcato@gmail.com \
--cc=brauner@kernel.org \
--cc=broonie@kernel.org \
--cc=ebiederm@xmission.com \
--cc=keescook@chromium.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux@weissschuh.net \
--cc=sebott@redhat.com \
--cc=stable@vger.kernel.org \
--cc=viro@zeniv.linux.org.uk \
--cc=w@1wt.eu \
/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