linux-kernel - Re: [PATCH RFC] binfmt_elf: fully allocate bss pages

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <36e93c8e-4384-b269-be78-479ccc7817b1@redhat.com>
Date:   Thu, 21 Sep 2023 12:36:34 +0200 (CEST)
From:   Sebastian Ott <sebott@...hat.com>
To:     Thomas Weißschuh <linux@...ssschuh.net>
cc:     Alexander Viro <viro@...iv.linux.org.uk>,
        Christian Brauner <brauner@...nel.org>,
        Eric Biederman <ebiederm@...ssion.com>,
        Kees Cook <keescook@...omium.org>,
        Mark Brown <broonie@...nel.org>, Willy Tarreau <w@....eu>,
        linux-fsdevel@...r.kernel.org, linux-mm@...ck.org,
        linux-kernel@...r.kernel.org, stable@...r.kernel.org
Subject: Re: [PATCH RFC] binfmt_elf: fully allocate bss pages

Hej,

since we figured that the proposed patch is not going to work I've spent a
couple more hours looking at this (some static binaries on arm64 segfault
during load [0]). The segfault happens because of a failed clear_user()
call in load_elf_binary(). The address we try to write zeros to is mapped with
correct permissions.

After some experiments I've noticed that writing to anonymous mappings work
fine and all the error cases happend on file backed VMAs. Debugging showed that
in elf_map() we call vm_mmap() with a file offset of 15 pages - for a binary
that's less than 1KiB in size.

Looking at the ELF headers again that 15 pages offset originates from the offset
of the 2nd segment - so, I guess the loader did as instructed and that binary is
just too nasty?

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

As an additional test I've added a bunch of zeros at the end of that binary
so that the offset is within that file and it did load just fine.

On the other hand there is this section header:
   [ 4] .bss              NOBITS           000000000041ffe8  0000ffe8
        0000000000000008  0000000000000000  WA       0     0     1

"sh_offset
This member's value gives the byte offset from the beginning of the file to
the first byte in the section. One section type, SHT_NOBITS described
below, occupies no space in the file, and its sh_offset member locates
the conceptual placement in the file.
"

So, still not sure what to do here..

Sebastian

[0] https://lore.kernel.org/lkml/5d49767a-fbdc-fbe7-5fb2-d99ece3168cb@redhat.com/