[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <cfd3e288-c913-482d-a6ce-789fa6b0f2b3@lucifer.local>
Date: Tue, 3 Dec 2024 14:13:45 +0000
From: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>
To: Kees Cook <kees@...nel.org>
Cc: akpm@...ux-foundation.org, jannh@...gle.com, sroettger@...gle.com,
adhemerval.zanella@...aro.org, ojeda@...nel.org, adobriyan@...il.com,
jeffxu@...omium.org, linux-kernel@...r.kernel.org, linux-mm@...ck.org,
jorgelo@...omium.org, linux-hardening@...r.kernel.org
Subject: Re: [PATCH v2 0/1] binfmt_elf: seal address zero
On Wed, Aug 14, 2024 at 09:59:47AM -0700, Kees Cook wrote:
> On Tue, 06 Aug 2024 21:49:26 +0000, jeffxu@...omium.org wrote:
> > From: Jeff Xu <jeffxu@...omium.org>
> >
> > In load_elf_binary as part of the execve(), when the current
> > task’s personality has MMAP_PAGE_ZERO set, the kernel allocates
> > one page at address 0. According to the comment:
> >
> > /* Why this, you ask??? Well SVr4 maps page 0 as read-only,
> > and some applications "depend" upon this behavior.
> > Since we do not have the power to recompile these, we
> > emulate the SVr4 behavior. Sigh. */
> >
> > [...]
>
> I added the cover letter details to the commit log and changed pr_warn()
> to pr_warn_ratelimited(), but otherwise, looked good.
>
> Applied to for-next/execve, thanks!
>
> [1/1] binfmt_elf: mseal address zero
> https://git.kernel.org/kees/c/44f65d900698
>
> Take care,
>
> --
> Kees Cook
>
>
Hi Kees,
Reproducing diffstat here:
fs/binfmt_elf.c | 5 +++++
include/linux/mm.h | 10 ++++++++++
mm/mseal.c | 2 +-
3 files changed, 16 insertions(+), 1 deletion(-)
It seems that in commit 44f65d9006982 ("binfmt_elf: mseal address zero")
you took a patch that makes changes to mm code without any review/ack from
any mm maintainer.
While I realise this was a small change, in future can you make sure to
ensure you have that?
I know linux-mm was cc'd but clearly it was missed.
Thanks, Lorenzo
Powered by blists - more mailing lists