Sorry for the delay in my reply -- I've been trying to catch up on stuff after 2 weeks off. On Tue, Dec 03, 2024 at 02:13:45PM +0000, Lorenzo Stoakes wrote: > On Wed, Aug 14, 2024 at 09:59:47AM -0700, Kees Cook wrote: > > On Tue, 06 Aug 2024 21:49:26 +0000, jeffxu@xxxxxxxxxxxx wrote: > > > From: Jeff Xu <jeffxu@xxxxxxxxxxxx> > > > > > > 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? Oh, yes! I can do that. As you say, it was a very small change and almost entirely "standard" boilerplate. But sure, I will be poke people more directly if anything touches mm in the future. -Kees -- Kees Cook
