linux-kernel - Re: Issue With Kernel Changes To Core Dump Collection (Kernel Bug...?)

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] [day] [month] [year] [list]

Message-ID: <CAG48ez0Om2MD9nn-NSPjtNvQ4DCX=Xakk+A2CqgXcOwxPzPNKQ@mail.gmail.com>
Date:   Fri, 21 Jan 2022 19:39:11 +0100
From:   Jann Horn <jannh@...gle.com>
To:     Bill Messmer <wmessmer@...rosoft.com>
Cc:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Randy Dunlap <rdunlap@...radead.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: Issue With Kernel Changes To Core Dump Collection (Kernel Bug...?)

On Fri, Jan 21, 2022 at 7:18 PM Randy Dunlap <rdunlap@...radead.org> wrote:
> On 1/20/22 17:31, Bill Messmer wrote:
> > Hello,
> >
> > It has been my understanding for some time that the kernel config option CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS (and the corresponding bit 4 of the coredump filter) was, at one point, added for the purpose of ensuring that the GNU build-id of ELF objects was included in core dumps.  The config description in Kconfig.binfmt even alludes to this in its description.
> >
> > I am trying to understand why in the 5.10+ kernels, there was a change in the kernel that, instead of checking whether a given memory mapping had an ELF header in order to determine whether to include the page to checking whether the inode is executable.  The change in question:
> >
> >       github.com/torvalds/linux/commit/429a22e776a2b9f85a2b9c53d8e647598b553dd1

As the commit message says, it was an attempt to avoid a deadlock
without making the code overly complicated. Clearly that didn't go as
planned...

> > In many distributions (e.g.: Ubuntu), the shared objects in /usr/lib and elsewhere are not marked as executable.

Urgh, crap. I'm looking around on my Debian box now, and I also see
that some libraries (like ld.so and libc) are marked executable, but
many others are not...

[...]
> > Was the change here really the intent...?  or is this a kernel bug?

Yeah, that's a bug. Linus suggested it as a way to simplify my
original patch (https://lore.kernel.org/all/CAHk-=wiOqR-4jXpPe-5PBKSCwQQFDaiJwkJr6ULwhcN8DJoG0A@mail.gmail.com/)
and it seemed like a good idea to me...

I guess the good news is that the original patch
https://lore.kernel.org/all/20200818061239.29091-5-jannh@google.com/
already has the code for doing it properly, so it should be pretty
straightforward to fix this by just pasting over some bits from the
old patch... I'll try to get around to that soon.

This would be so much nicer if the kernel actually knew what is a
library mapping and what isn't... oh well.