From: Pedro Falcato <pedro.falcato@gmail.com>
To: Kees Cook <keescook@chromium.org>
Cc: "Eric Biederman" <ebiederm@xmission.com>,
"Sebastian Ott" <sebott@redhat.com>,
"Thomas Weißschuh" <linux@weissschuh.net>,
"Al Viro" <viro@zeniv.linux.org.uk>,
"Christian Brauner" <brauner@kernel.org>,
"Andrew Morton" <akpm@linux-foundation.org>,
linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org,
linux-mm@kvack.org, linux-hardening@vger.kernel.org
Subject: Re: [PATCH v4 0/6] binfmt_elf: Support segments with 0 filesz and misaligned starts
Date: Fri, 29 Sep 2023 12:58:18 +0100 [thread overview]
Message-ID: <CAKbZUD3dxYqb4RSnXFs9ehWymXe15pt8ra232WAD_msJsBF_BQ@mail.gmail.com> (raw)
In-Reply-To: <20230929031716.it.155-kees@kernel.org>
On Fri, Sep 29, 2023 at 4:24 AM Kees Cook <keescook@chromium.org> wrote:
>
> Hi,
>
> This is the continuation of the work Eric started for handling
> "p_memsz > p_filesz" in arbitrary segments (rather than just the last,
> BSS, segment). I've added the suggested changes:
>
> - drop unused "elf_bss" variable
> - refactor load_elf_interp() to use elf_load()
> - refactor load_elf_library() to use elf_load()
> - report padzero() errors when PROT_WRITE is present
> - drop vm_brk()
>
> Thanks!
>
> -Kees
>
> v4:
> - refactor load_elf_library() too
> - don't refactor padzero(), just test in the only remaining caller
> - drop now-unused vm_brk()
> v3: https://lore.kernel.org/all/20230927033634.make.602-kees@kernel.org
> v2: https://lore.kernel.org/lkml/87sf71f123.fsf@email.froward.int.ebiederm.org
> v1: https://lore.kernel.org/lkml/87jzsemmsd.fsf_-_@email.froward.int.ebiederm.org
>
> Eric W. Biederman (1):
> binfmt_elf: Support segments with 0 filesz and misaligned starts
>
> Kees Cook (5):
> binfmt_elf: elf_bss no longer used by load_elf_binary()
> binfmt_elf: Use elf_load() for interpreter
> binfmt_elf: Use elf_load() for library
> binfmt_elf: Only report padzero() errors when PROT_WRITE
> mm: Remove unused vm_brk()
>
> fs/binfmt_elf.c | 214 ++++++++++++++++-----------------------------
> include/linux/mm.h | 3 +-
> mm/mmap.c | 6 --
> mm/nommu.c | 5 --
> 4 files changed, 76 insertions(+), 152 deletions(-)
Sorry for taking so long to take a look at this.
While I didn't test PPC64 (I don't own PPC64 hardware, and I wasn't
the original reporter), I did manage to craft a reduced test case of:
a.out:
Program Headers:
Type Offset VirtAddr PhysAddr
FileSiz MemSiz Flags Align
PHDR 0x0000000000000040 0x0000000000000040 0x0000000000000040
0x00000000000001f8 0x00000000000001f8 R 0x8
INTERP 0x0000000000000238 0x0000000000000238 0x0000000000000238
0x0000000000000020 0x0000000000000020 R 0x1
[Requesting program interpreter: /home/pfalcato/musl/lib/libc.so]
LOAD 0x0000000000000000 0x0000000000000000 0x0000000000000000
0x0000000000000428 0x0000000000000428 R 0x1000
LOAD 0x0000000000001000 0x0000000000001000 0x0000000000001000
0x00000000000000cd 0x00000000000000cd R E 0x1000
LOAD 0x0000000000002000 0x0000000000002000 0x0000000000002000
0x0000000000000084 0x0000000000000084 R 0x1000
LOAD 0x0000000000002e50 0x0000000000003e50 0x0000000000003e50
0x00000000000001c8 0x00000000000001c8 RW 0x1000
DYNAMIC 0x0000000000002e50 0x0000000000003e50 0x0000000000003e50
0x0000000000000180 0x0000000000000180 RW 0x8
GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000
0x0000000000000000 0x0000000000000000 RW 0x10
GNU_RELRO 0x0000000000002e50 0x0000000000003e50 0x0000000000003e50
0x00000000000001b0 0x00000000000001b0 R 0x1
/home/pfalcato/musl/lib/libc.so:
Program Headers:
Type Offset VirtAddr PhysAddr
FileSiz MemSiz Flags Align
PHDR 0x0000000000000040 0x0000000000000040 0x0000000000000040
0x0000000000000230 0x0000000000000230 R 0x8
LOAD 0x0000000000000000 0x0000000000000000 0x0000000000000000
0x0000000000049d9c 0x0000000000049d9c R 0x1000
LOAD 0x0000000000049da0 0x000000000004ada0 0x000000000004ada0
0x0000000000057d30 0x0000000000057d30 R E 0x1000
LOAD 0x00000000000a1ad0 0x00000000000a3ad0 0x00000000000a3ad0
0x00000000000005f0 0x00000000000015f0 RW 0x1000
LOAD 0x00000000000a20c0 0x00000000000a60c0 0x00000000000a60c0
0x0000000000000428 0x0000000000002f80 RW 0x1000
DYNAMIC 0x00000000000a1f38 0x00000000000a3f38 0x00000000000a3f38
0x0000000000000110 0x0000000000000110 RW 0x8
GNU_RELRO 0x00000000000a1ad0 0x00000000000a3ad0 0x00000000000a3ad0
0x00000000000005f0 0x0000000000002530 R 0x1
GNU_EH_FRAME 0x0000000000049d10 0x0000000000049d10 0x0000000000049d10
0x0000000000000024 0x0000000000000024 R 0x4
GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000
0x0000000000000000 0x0000000000000000 RW 0x0
NOTE 0x0000000000000270 0x0000000000000270 0x0000000000000270
0x0000000000000018 0x0000000000000018 R 0x4
Section to Segment mapping:
Segment Sections...
00
01 .note.gnu.build-id .dynsym .gnu.hash .hash .dynstr .rela.dyn
.rela.plt .rodata .eh_frame_hdr .eh_frame
02 .text .plt
03 .data.rel.ro .dynamic .got .toc
04 .data .got.plt .bss
05 .dynamic
06 .data.rel.ro .dynamic .got .toc
07 .eh_frame_hdr
08
09 .note.gnu.build-id
So on that end, you can take my
Tested-by: Pedro Falcato <pedro.falcato@gmail.com>
Although this still doesn't address the other bug I found
(https://github.com/heatd/elf-bug-questionmark), where segments can
accidentally overwrite cleared BSS if we end up in a situation where
e.g we have the following segments:
Program Headers:
Type Offset VirtAddr PhysAddr
FileSiz MemSiz Flags Align
LOAD 0x0000000000001000 0x0000000000400000 0x0000000000400000
0x0000000000000045 0x0000000000000045 R E 0x1000
LOAD 0x0000000000002000 0x0000000000401000 0x0000000000401000
0x000000000000008c 0x000000000000008c R 0x1000
LOAD 0x0000000000000000 0x0000000000402000 0x0000000000402000
0x0000000000000000 0x0000000000000801 RW 0x1000
LOAD 0x0000000000002801 0x0000000000402801 0x0000000000402801
0x0000000000000007 0x0000000000000007 RW 0x1000
NOTE 0x0000000000002068 0x0000000000401068 0x0000000000401068
0x0000000000000024 0x0000000000000024 0x4
Section to Segment mapping:
Segment Sections...
00 .text
01 .rodata .note.gnu.property .note.gnu.build-id
02 .bss
03 .data
04 .note.gnu.build-id
since the mmap of .data will end up happening over .bss.
--
Pedro
next prev parent reply other threads:[~2023-09-29 11:58 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-29 3:24 Kees Cook
2023-09-29 3:24 ` [PATCH v4 1/6] " Kees Cook
2023-09-29 12:06 ` Pedro Falcato
2023-09-29 15:23 ` Eric W. Biederman
2023-09-29 3:24 ` [PATCH v4 2/6] binfmt_elf: elf_bss no longer used by load_elf_binary() Kees Cook
2023-09-29 3:24 ` [PATCH v4 3/6] binfmt_elf: Use elf_load() for interpreter Kees Cook
2023-09-29 3:24 ` [PATCH v4 4/6] binfmt_elf: Use elf_load() for library Kees Cook
2023-09-29 12:12 ` Pedro Falcato
2023-09-29 15:32 ` Eric W. Biederman
2023-09-29 17:06 ` Kees Cook
2023-09-29 3:24 ` [PATCH v4 5/6] binfmt_elf: Only report padzero() errors when PROT_WRITE Kees Cook
2023-09-29 3:24 ` [PATCH v4 6/6] mm: Remove unused vm_brk() Kees Cook
2023-09-29 11:33 ` [PATCH v4 0/6] binfmt_elf: Support segments with 0 filesz and misaligned starts Sebastian Ott
2023-09-29 15:45 ` Eric W. Biederman
2023-09-29 17:09 ` Kees Cook
2023-09-29 11:58 ` Pedro Falcato [this message]
2023-09-29 15:39 ` Eric W. Biederman
2023-09-29 17:07 ` Kees Cook
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=CAKbZUD3dxYqb4RSnXFs9ehWymXe15pt8ra232WAD_msJsBF_BQ@mail.gmail.com \
--to=pedro.falcato@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=brauner@kernel.org \
--cc=ebiederm@xmission.com \
--cc=keescook@chromium.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-hardening@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux@weissschuh.net \
--cc=sebott@redhat.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox