From: Andrew Morton <akpm@linux-foundation.org>
To: mm-commits@vger.kernel.org,ljs@kernel.org,akpm@linux-foundation.org
Subject: [to-be-updated] mm-mseal-remove-further-superfluous-comments-do_mseal.patch removed from -mm tree
Date: Fri, 17 Jul 2026 12:35:12 -0700 [thread overview]
Message-ID: <20260717193512.DF27D1F000E9@smtp.kernel.org> (raw)
The quilt patch titled
Subject: mm/mseal: remove further superfluous comments, do_mseal()
has been removed from the -mm tree. Its filename was
mm-mseal-remove-further-superfluous-comments-do_mseal.patch
This patch was dropped because an updated version will be issued
------------------------------------------------------
From: "Lorenzo Stoakes (ARM)" <ljs@kernel.org>
Subject: mm/mseal: remove further superfluous comments, do_mseal()
Date: Thu, 16 Jul 2026 14:43:11 +0100
There's no need to abstract do_mseal() any longer so put the system call
implementation in the system call declaration.
The comment around do_mseal() is strangely formatted, overly long and adds
a lot of superfluous information that the code already provides, so boil
it down to the essentials.
Link: https://lore.kernel.org/20260716-mseal-fixups-v1-3-3a9609bf041b@kernel.org
Signed-off-by: Lorenzo Stoakes (ARM) <ljs@kernel.org>
Reviewed-by: Pedro Falcato <pfalcato@suse.de>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: Christian Brauner <brauner@kernel.org>
Cc: David Hildenbrand <david@kernel.org>
Cc: Jan Kara <jack@suse.cz>
Cc: Jann Horn <jannh@google.com>
Cc: Kees Cook <kees@kernel.org>
Cc: Liam R. Howlett <liam@infradead.org>
Cc: Michal Hocko <mhocko@suse.com>
Cc: Mike Rapoport <rppt@kernel.org>
Cc: Suren Baghdasaryan <surenb@google.com>
Cc: Vlastimil Babka <vbabka@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
mm/mseal.c | 74 +++++++++++----------------------------------------
1 file changed, 16 insertions(+), 58 deletions(-)
--- a/mm/mseal.c~mm-mseal-remove-further-superfluous-comments-do_mseal
+++ a/mm/mseal.c
@@ -99,60 +99,24 @@ void mseal_mmap_page_zero(void)
}
/*
- * mseal(2) seals the VM's meta data from
- * selected syscalls.
+ * Seal VMAs in the specified input range to prevent an attacker replacing what
+ * is mapped in the range with something else.
*
- * addr/len: VM address range.
+ * Disallows:
+ * - VMA unmapping, remapping or shrinking.
+ * - Overwriting the VMA with another one via mmap(), mremap() or similar.
+ * - Alteration of properties via mprotect()/pkey_mprotect().
+ * - Destructive madvise() behaviours (like MADV_DONTNEED) on anonymous read-only
+ * ranges.
*
- * The address range by addr/len must meet:
- * start (addr) must be in a valid VMA.
- * end (addr + len) must be in a valid VMA.
- * no gap (unallocated memory) between start and end.
- * start (addr) must be page aligned.
+ * Since unmapped ranges can be mapped at any time, the input range must span
+ * mapped ranges only.
*
- * len: len will be page aligned implicitly.
- *
- * Below VMA operations are blocked after sealing.
- * 1> Unmapping, moving to another location, and shrinking
- * the size, via munmap() and mremap(), can leave an empty
- * space, therefore can be replaced with a VMA with a new
- * set of attributes.
- * 2> Moving or expanding a different vma into the current location,
- * via mremap().
- * 3> Modifying a VMA via mmap(MAP_FIXED).
- * 4> Size expansion, via mremap(), does not appear to pose any
- * specific risks to sealed VMAs. It is included anyway because
- * the use case is unclear. In any case, users can rely on
- * merging to expand a sealed VMA.
- * 5> mprotect and pkey_mprotect.
- * 6> Some destructive madvice() behavior (e.g. MADV_DONTNEED)
- * for anonymous memory, when users don't have write permission to the
- * memory. Those behaviors can alter region contents by discarding pages,
- * effectively a memset(0) for anonymous memory.
- *
- * flags: reserved.
- *
- * return values:
- * zero: success.
- * -EINVAL:
- * invalid input flags.
- * start address is not page aligned.
- * Address range (start + len) overflow.
- * -ENOMEM:
- * addr is not a valid address (not allocated).
- * end (start + len) is not a valid address.
- * a gap (unallocated memory) between start and end.
- * -EPERM:
- * - In 32 bit architecture, sealing is not supported.
- * Note:
- * user can call mseal(2) multiple times, adding a seal on an
- * already sealed memory is a no-action (no error).
- *
- * unseal() is not supported.
+ * The flags parameter is currently reserved.
*/
-static int do_mseal(unsigned long start, size_t len_in, unsigned long flags)
+SYSCALL_DEFINE3(mseal, unsigned long, start, size_t, len, unsigned long, flags)
{
- size_t len;
+ size_t len_aligned;
unsigned long end;
/* Verify flags not set. */
@@ -163,12 +127,12 @@ static int do_mseal(unsigned long start,
if (!PAGE_ALIGNED(start))
return -EINVAL;
- len = PAGE_ALIGN(len_in);
+ len_aligned = PAGE_ALIGN(len);
/* Check to see whether len was rounded up from small -ve to zero. */
- if (len_in && !len)
+ if (len && !len_aligned)
return -EINVAL;
- end = start + len;
+ end = start + len_aligned;
if (end < start)
return -EINVAL;
@@ -177,9 +141,3 @@ static int do_mseal(unsigned long start,
return mseal(start, end);
}
-
-SYSCALL_DEFINE3(mseal, unsigned long, start, size_t, len, unsigned long,
- flags)
-{
- return do_mseal(start, len, flags);
-}
_
Patches currently in -mm which might be from ljs@kernel.org are
mm-vmalloc-acquire-init_mm-lock-on-huge-vmap-to-avoid-ptdump-uaf.patch
x86-mm-pat-acquire-init_mm-write-lock-on-collapse-to-avoid-uaf.patch
x86-mm-pat-acquire-init_mm-read-lock-on-attribute-change-to-avoid-uaf.patch
mm-ptdump-always-stabilise-against-page-table-freeing-using-init_mm.patch
arm64-remove-redundant-concurrent-ptdump-uaf-mitigation.patch
mm-move-alloc-tag-to-mm.patch
mm-move-vma_start_pgoff-into-mmh-and-clean-up.patch
mm-add-kdoc-comments-for-vma_start-last_pgoff.patch
tools-testing-vma-use-vma_start_pgoff-in-merge-tests.patch
mm-introduce-and-use-vma_end_pgoff.patch
mm-rmap-update-mm-interval_treec-comments.patch
mm-rmap-parameterise-vma_interval_tree_-by-address_space.patch
mm-rmap-elide-unnecessary-static-inlines-in-interval_treec.patch
mm-rmap-rename-vma_interval_tree_-to-mapping_rmap_tree_.patch
mm-rmap-parameterise-anon_vma_interval_tree_-by-anon_vma.patch
mm-rmap-rename-anon_vma_interval_tree_-params-and-use-pgoff_t.patch
mm-rmap-rename-anon_vma_interval_tree_-to-anon_rmap_tree_.patch
maintainers-move-mm-interval_treec-to-rmap-section.patch
mm-vma-introduce-and-use-vmg_pages-vmg__pgoff.patch
mm-vma-clean-up-anon_vma_compatible.patch
mm-vma-refactor-vmg_adjust_set_range-for-clarity.patch
mm-vma-minor-cleanup-of-expand_.patch
mm-introduce-and-use-linear_page_delta.patch
mm-vma-use-vma_start_pgoff-linear_page_index-in-mm-code.patch
mm-prefer-vma__pgoff-to-vma-vm_pgoff-in-kernel.patch
mm-vma-remove-duplicative-vma_pgoff_offset-helper.patch
mm-use-linear_page_-consistently.patch
mm-vma-introduce-vma_assert_can_modify.patch
mm-vma-add-and-use-vma__pgoff.patch
mm-vma-move-__install_special_mapping-to-vmac.patch
mm-vma-make-vma_set_range-static-drop-insert_vm_struct-decl.patch
mm-vma-update-vma_shrink-to-not-pass-start-pgoff-parameters.patch
mm-vma-update-vmg_adjust_set_range-to-offset-pgoff-instead.patch
mm-vma-slightly-rework-the-anonymous-check-in-__mmap_new_vma.patch
mm-vma-introduce-and-use-vma_set_pgoff.patch
mm-vma-correct-incorrect-vmah-inclusion.patch
mm-vma-use-guard-clauses-in-can_vma_merge_.patch
tools-testing-vma-default-vma-mm-flag-bits-to-64-bit.patch
tools-testing-vma-output-compared-expression-on-assert_.patch
mm-introduce-vma_flags_can_grow-and-vma_can_grow.patch
mm-vma-update-do_mmap-to-use-vma_flags_t.patch
mm-convert-__get_unmapped_area-to-use-vma_flags_t.patch
mm-update-generic_get_unmapped_area-to-use-vma_flags_t.patch
mm-prefer-mm-def_vma_flags-in-mm-logic.patch
mm-vma-convert-vm_pgprot_modify-to-use-vma_flags_t-and-rename.patch
mm-vma-rename-vma_get_page_prot-to-vma_flags_to_page_prot.patch
mm-introduce-vma_get_page_prot-and-use-it.patch
mm-vma-update-create_init_stack_vma-to-use-vma_flags_t.patch
mm-vma-convert-miscellaneous-uses-of-vma-flags-in-core-mm.patch
mm-mlock-convert-mlock-code-to-use-vma_flags_t.patch
mm-mprotect-convert-mprotect-code-to-use-vma_flags_t.patch
mm-mremap-convert-mremap-code-to-use-vma_flags_t.patch
reply other threads:[~2026-07-17 19:35 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=20260717193512.DF27D1F000E9@smtp.kernel.org \
--to=akpm@linux-foundation.org \
--cc=ljs@kernel.org \
--cc=mm-commits@vger.kernel.org \
/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.