From: "David Hildenbrand (Arm)" <david@kernel.org>
To: "Lorenzo Stoakes (ARM)" <ljs@kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
"Liam R. Howlett" <liam@infradead.org>,
Vlastimil Babka <vbabka@kernel.org>, Jann Horn <jannh@google.com>,
Pedro Falcato <pfalcato@suse.de>,
Alexander Viro <viro@zeniv.linux.org.uk>,
Christian Brauner <brauner@kernel.org>, Jan Kara <jack@suse.cz>,
Kees Cook <kees@kernel.org>, Mike Rapoport <rppt@kernel.org>,
Suren Baghdasaryan <surenb@google.com>,
Michal Hocko <mhocko@suse.com>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH 2/3] mm/mseal: limit scope of mseal address zero to address zero
Date: Fri, 17 Jul 2026 11:46:49 +0100 [thread overview]
Message-ID: <c1fa877e-de9d-4d85-9d2b-6971f0cbd7ff@kernel.org> (raw)
In-Reply-To: <20260716-mseal-fixups-v1-2-3a9609bf041b@kernel.org>
On 7/16/26 15:43, Lorenzo Stoakes (ARM) wrote:
> Commit 44f65d900698 ("binfmt_elf: mseal address zero") unconditionally
> provided do_mseal() to any internal kernel caller in order to address a
> corner case slated for possible removal.
>
> It also incorrectly attempts to mseal() without checking to see whether the
> mapping even succeeded.
>
> Restrict the scope to the corner case by providing mseal_mmap_page_zero()
> which asserts the MMAP_PAGE_ZERO personality.
>
> Avoid unnecessary checks in the start, end range by abstracting the actual
> mseal()'ing to mseal() and have mseal_mmap_page_zero() call that instead.
>
> Only try to seal the VMA if we mapped the VMA.
>
> Signed-off-by: Lorenzo Stoakes (ARM) <ljs@kernel.org>
> ---
> fs/binfmt_elf.c | 7 ++-----
> include/linux/mm.h | 8 ++------
> mm/mseal.c | 48 +++++++++++++++++++++++++++++++++++-------------
> 3 files changed, 39 insertions(+), 24 deletions(-)
>
> diff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c
> index 16a56b6b3f6c..e3131a311995 100644
> --- a/fs/binfmt_elf.c
> +++ b/fs/binfmt_elf.c
> @@ -1353,11 +1353,8 @@ static int load_elf_binary(struct linux_binprm *bprm)
> emulate the SVr4 behavior. Sigh. */
> error = vm_mmap(NULL, 0, PAGE_SIZE, PROT_READ | PROT_EXEC,
> MAP_FIXED | MAP_PRIVATE, 0);
> -
> - retval = do_mseal(0, PAGE_SIZE, 0);
> - if (retval)
> - pr_warn_ratelimited("pid=%d, couldn't seal address 0, ret=%d.\n",
> - task_pid_nr(current), retval);
> + if (!error)
> + mseal_mmap_page_zero();
> }
>
> regs = current_pt_regs();
> diff --git a/include/linux/mm.h b/include/linux/mm.h
> index 550fb92957d1..87feaa5a2b78 100644
> --- a/include/linux/mm.h
> +++ b/include/linux/mm.h
> @@ -5291,13 +5291,9 @@ int reserve_mem_find_by_name(const char *name, phys_addr_t *start, phys_addr_t *
> int reserve_mem_release_by_name(const char *name);
>
> #ifdef CONFIG_64BIT
> -int do_mseal(unsigned long start, size_t len_in, unsigned long flags);
> +void mseal_mmap_page_zero(void);
do_mseal() gone here, nice.
> #else
> -static inline int do_mseal(unsigned long start, size_t len_in, unsigned long flags)
> -{
> - /* noop on 32 bit */
> - return 0;
> -}
> +static inline void mseal_mmap_page_zero(void) {}
> #endif
>
> /*
> diff --git a/mm/mseal.c b/mm/mseal.c
> index 207fea89c61e..5930551d84f2 100644
> --- a/mm/mseal.c
> +++ b/mm/mseal.c
> @@ -32,7 +32,7 @@ static bool range_contains_unmapped(unsigned long start, unsigned long end)
> return prev_end < end;
> }
>
> -static int mseal_apply(unsigned long start, unsigned long end)
> +static int __mseal(unsigned long start, unsigned long end)
> {
> struct vm_area_struct *vma, *prev;
> VMA_ITERATOR(vmi, current->mm, start);
> @@ -66,6 +66,38 @@ static int mseal_apply(unsigned long start, unsigned long end)
> return 0;
> }
>
> +static int mseal(unsigned long start, unsigned long end)
mseal_range() could be indeed nicer. But do_mseal() is now a pure helper for
"SYSCALL_DEFINE3(mseal" only ...could we simply inline do_mseal into
SYSCALL_DEFINE3(mseal)?
We could do that separately, ofc.
--
Cheers,
David
next prev parent reply other threads:[~2026-07-17 10:46 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-16 13:43 [PATCH 0/3] mm/mseal: further cleanups Lorenzo Stoakes (ARM)
2026-07-16 13:43 ` [PATCH 1/3] mm/mseal: remove superfluous comments, fix confusion around mm Lorenzo Stoakes (ARM)
2026-07-16 15:00 ` Pedro Falcato
2026-07-17 10:33 ` David Hildenbrand (Arm)
2026-07-17 10:44 ` Lorenzo Stoakes (ARM)
2026-07-16 13:43 ` [PATCH 2/3] mm/mseal: limit scope of mseal address zero to address zero Lorenzo Stoakes (ARM)
2026-07-16 15:06 ` Pedro Falcato
2026-07-16 15:38 ` Lorenzo Stoakes (ARM)
2026-07-17 10:41 ` David Hildenbrand (Arm)
2026-07-17 10:51 ` Lorenzo Stoakes (ARM)
2026-07-17 10:46 ` David Hildenbrand (Arm) [this message]
2026-07-17 10:49 ` David Hildenbrand (Arm)
2026-07-17 10:52 ` Lorenzo Stoakes (ARM)
2026-07-16 13:43 ` [PATCH 3/3] mm/mseal: remove further superfluous comments, do_mseal() Lorenzo Stoakes (ARM)
2026-07-16 15:09 ` Pedro Falcato
2026-07-16 15:13 ` Lorenzo Stoakes (ARM)
2026-07-17 0:33 ` Andrew Morton
2026-07-17 11:06 ` Lorenzo Stoakes (ARM)
2026-07-17 10:50 ` David Hildenbrand (Arm)
2026-07-17 10:55 ` Lorenzo Stoakes (ARM)
2026-07-16 13:48 ` [PATCH 0/3] mm/mseal: further cleanups Lorenzo Stoakes (ARM)
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=c1fa877e-de9d-4d85-9d2b-6971f0cbd7ff@kernel.org \
--to=david@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=brauner@kernel.org \
--cc=jack@suse.cz \
--cc=jannh@google.com \
--cc=kees@kernel.org \
--cc=liam@infradead.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=ljs@kernel.org \
--cc=mhocko@suse.com \
--cc=pfalcato@suse.de \
--cc=rppt@kernel.org \
--cc=surenb@google.com \
--cc=vbabka@kernel.org \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.