From c79cf15eb35a4c703bf18f8c33c47e80dd660f8e Mon Sep 17 00:00:00 2001 From: Hao Ge Date: Thu, 27 Aug 2026 11:05:03 +0800 Subject: [PATCH 01/10] module: fix lost error code from codetag_load_module() If codetag_load_module() fails, err is not set to reflect the failure and load_module() returns 0 after the module has been torn down. Also, if the module is a livepatch, mod->klp_info allocated by copy_module_elf() leaks on this error path. Free it via a new livepatch_cleanup label. Link: https://lore.kernel.org/20260827030503.49171-1-hao.ge@linux.dev Fixes: 044d2aee6c57 ("alloc_tag: handle module codetag load errors as module load failures") Signed-off-by: Hao Ge Signed-off-by: Andrew Morton Reported-by: Sashiko Suggested-by: Petr Pavlu Reviewed-by: Bradley Morgan Cc: Aaron Tomlin Cc: Luis Chamberalin Cc: Sami Tolvanen Cc: Suren Baghdasaryan Cc: --- kernel/module/main.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/kernel/module/main.c b/kernel/module/main.c index d0e1e0bd2ad0..c1b34dc1e89a 100644 --- a/kernel/module/main.c +++ b/kernel/module/main.c @@ -3581,8 +3581,9 @@ static int load_module(struct load_info *info, const char __user *uargs, goto sysfs_cleanup; } - if (codetag_load_module(mod)) - goto sysfs_cleanup; + err = codetag_load_module(mod); + if (err) + goto livepatch_cleanup; /* Get rid of temporary copy. */ free_copy(info, flags); @@ -3592,6 +3593,9 @@ static int load_module(struct load_info *info, const char __user *uargs, return do_init_module(mod); + livepatch_cleanup: + if (is_livepatch_module(mod)) + free_module_elf(mod); sysfs_cleanup: mod_sysfs_teardown(mod); coming_cleanup: From 72c3d682c165b836b54a3d07a01f72e39c47022c Mon Sep 17 00:00:00 2001 From: Baolin Wang Date: Mon, 14 Sep 2026 10:12:41 +0800 Subject: [PATCH 02/10] mm: shmem: ignore sysfs configs for shmem forced collapse According to Documentation/mm/transhuge.rst, MADV_COLLAPSE is expected to ignore any THP or mTHP interface settings. However, after commit 26c7d8413aaf ("mm: thp: support "THPeligible" semantics for mTHP with anonymous shmem"), performing MADV_COLLAPSE on shmem will depend on /sys/.../hugepages-2048kB/shmem_enabled being set to "inherit" (although that is the default), which can cause MADV_COLLAPSE to fail unexpectedly. This could cause a userspace-visible performance regression. Fix this by returning the result of shmem_huge_global_enabled() directly when MADV_COLLAPSE is requested, allowing PMD-order collapse while ignoring shmem THP/mTHP settings. Link: https://lore.kernel.org/063f655b4d6c4234f3aa27ed6ecab10283ecb880.1789351825.git.baolin.wang@linux.alibaba.com Fixes: 26c7d8413aaf ("mm: thp: support "THPeligible" semantics for mTHP with anonymous shmem") Signed-off-by: Baolin Wang Signed-off-by: Andrew Morton Reported-by: Kiryl Shutsemau (Meta) Closes: https://lore.kernel.org/all/20260908125105.1510704-7-kirill@shutemov.name/ Reviewed-by: Kiryl Shutsemau (Meta) Acked-by: Zi Yan Reviewed-by: Lance Yang Reviewed-by: Barry Song Acked-by: Qi Zheng Acked-by: David Hildenbrand (Arm) Reviewed-by: Lorenzo Stoakes (ARM) Cc: Dev Jain Cc: Hugh Dickins Cc: Liam R. Howlett Cc: Ryan Roberts Cc: --- mm/shmem.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/mm/shmem.c b/mm/shmem.c index 897fa2b61346..848316eaa7f4 100644 --- a/mm/shmem.c +++ b/mm/shmem.c @@ -1847,8 +1847,11 @@ unsigned long shmem_allowable_huge_orders(struct inode *inode, global_orders = shmem_huge_global_enabled(inode, index, write_end, shmem_huge_force, vma, vm_flags); - /* Tmpfs huge pages allocation */ - if (!vma || !vma_is_anon_shmem(vma)) + /* + * Tmpfs huge pages allocation or forced collapse ignores + * sysfs configs. + */ + if (!vma || !vma_is_anon_shmem(vma) || shmem_huge_force) return global_orders; /* From 347c6ed8cf7768883252e106994de62c7947f0a0 Mon Sep 17 00:00:00 2001 From: Arnd Bergmann Date: Tue, 15 Sep 2026 22:23:47 +0200 Subject: [PATCH 03/10] alloc_tag: avoid implicit padding in uapi The implied padding causes a harmless warning when testing the uapi headers with -Wpadded that could in theory indicate incompatibilities or data leaks: ./usr/include/linux/alloc_tag.h:41:1: error: padding struct size to alignment boundary with 7 bytes [-Werror=padded] The code here is fine, but it's better to make the padding explicit and avoid the warning here. Link: https://lore.kernel.org/20260916065830.1619425-1-arnd@kernel.org Link: https://lore.kernel.org/20260915202404.3568029-1-arnd@kernel.org Fixes: 1d581ab2348c ("alloc_tag: add ioctl to /proc/allocinfo") Signed-off-by: Arnd Bergmann Signed-off-by: Andrew Morton Acked-by: Suren Baghdasaryan Acked-by: SJ Park Acked-by: Hao Ge --- include/uapi/linux/alloc_tag.h | 1 + 1 file changed, 1 insertion(+) diff --git a/include/uapi/linux/alloc_tag.h b/include/uapi/linux/alloc_tag.h index e3ad94444864..7d4618bea043 100644 --- a/include/uapi/linux/alloc_tag.h +++ b/include/uapi/linux/alloc_tag.h @@ -38,6 +38,7 @@ struct allocinfo_counter { __u64 bytes; __u64 calls; __u8 accurate; + __u8 pad[7]; } __attribute__((aligned(8))); struct allocinfo_tag_data { From 52ae167ce16609c7e6fffef588b3c2c26de2db19 Mon Sep 17 00:00:00 2001 From: SJ Park Date: Wed, 16 Sep 2026 06:50:19 -0700 Subject: [PATCH 04/10] mm/damon/core: don't skip damos_adjust_quota() while esz is not zero DAMOS could unexpectedly stop working when a user disables quota using the online parameters commit feature. Fix it by correcting a wrong quota unset check in damos_adjust_quota(). DAMON users could disable all quotas by unsetting time and size quotas, and removing all quota goals. The intention of disabling quotas would be making DAMOS run at full speed. When such quota disabled setup is detected, damos_adjust_quota() skips all its work. The skipped works include effective size quota (damos_quota->esz) updates and charged quota amount (damos_quota->charged_sz) resets. The intention is to avoid doing unnecessary work when quotas are disabled. However, users could do the setup while effective size quota is non-zero, by doing the disabling with the online DAMON parameters commit feature. In this case, because the effective size quota exists, DAMOS will keep working with the quota until it is fully charged. After the effective quota is fully charged, the charged quota amount (damos_quota->charged_sz) cannot be reset because damos_adjust_quota() skips it. Then, DAMOS stops working until the quota is newly set or DAMON is entirely restarted. The problem happens because damos_adjust_quota() assumes the user setup for disabling quota immediately disabled it. In reality, the quota is still working until the effective size quota is also updated to zero. Other logic for catching that uses damos_quota_is_set(), which understands the fact and therefore checks the effective size quota in addition to the user setup. Fix the issue by using damos_quota_is_set() in damos_adjust_quota() to determine if its works should be skipped. The user impact is a non-deterministic and unexpected DAMOS stop behavior. That is, users would disable quotas using the online parameters commit feature, expecting DAMOS will run at full speed. However, depending on the timing, the setup can be updated while the effective size quota is non-zero. Due to the above mentioned internal mechanism, DAMOS stops working instead of running at full speed. It is unexpected behavior. It is also non-deterministic because sometimes the setup is done when the effective size quota is zero, depending on the timing. It doesn't cause critical issues like crashes or leaks. Users can simply set a reasonable quota again, or restart DAMON. But definitely it is an unexpected and non-deterministic behavior that makes it difficult to reliably use. Also investigating the root cause of the behavior would be quite difficult. Link: https://lore.kernel.org/20260916135020.86483-1-sj@kernel.org Fixes: da87878010e5 ("mm/damon/sysfs: support online inputs update") Signed-off-by: SJ Park Signed-off-by: Andrew Morton Reviewed-by: Kunwu Chan Cc: # 5.19.x --- mm/damon/core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/mm/damon/core.c b/mm/damon/core.c index 1764620903f2..ab3c4d754964 100644 --- a/mm/damon/core.c +++ b/mm/damon/core.c @@ -3147,7 +3147,7 @@ static void damos_adjust_quota(struct damon_ctx *c, struct damos *s) unsigned long cumulated_sz, cached_esz; unsigned int score, max_score = 0; - if (!quota->ms && !quota->sz && list_empty("a->goals)) + if (!damos_quota_is_set(quota)) return; /* First charge window */ From 22ab0647764c38924669673634ae333578d77768 Mon Sep 17 00:00:00 2001 From: Andrey Ryabinin Date: Wed, 16 Sep 2026 19:51:13 +0200 Subject: [PATCH 05/10] kasan: unpoison task stack below watermark only in generic mode CPU resume and BPF exception handling can discard stack frames without running their compiler-generated epilogues. Generic KASAN needs kasan_unpoison_task_stack_below() to clear the redzones left behind by those frames before the stack is reused. CONFIG_KASAN_STACK also enables this helper for SW_TAGS. The helper derives the stack base from an untagged stack pointer, so kasan_unpoison() writes KASAN_TAG_KERNEL (0xff) into the shadow for [base, watermark). For a vmapped task stack, vm_area->addr still carries the original random allocation tag. This creates a tag mismatch at the stack base even if that memory has never held an instrumented stack object. When the task exits and its stack is not cached, thread_stack_free_rcu() passes vm_area->addr to vfree(). In RCU callback context this reaches vfree_atomic(), whose llist_add() writes to the allocation base through the tagged pointer and triggers a false KASAN invalid-access report: BUG: KASAN: invalid-access in vfree_atomic+0x90/0x150 Write of size 8 at addr c2ffffc0a8f70000 by task rcuop/7/75 Pointer tag: [c2], memory tag: [ff] Call trace: __hwasan_store8_noabort+0xe8/0xf8 vfree_atomic+0x90/0x150 vfree+0x220/0x298 thread_stack_free_rcu+0x3c/0x4c rcu_do_batch+0x308/0xaf0 rcu_nocb_cb_kthread+0x33c/0x708 The deferred-free path started using the tagged vm_area->addr in commit 449e0b4ed5a1 ("fork: clean-up naming of vm_stack/vm_struct variables in vmap stacks code"). Previously it freed the untagged pointer derived from tsk->stack, so the write was never tag-checked. SW_TAGS does not need the blanket shadow reset to make subsequent stack accesses valid: untagged kernel pointers have the match-all 0xff tag, and the compiler initializes the shadow tags of instrumented stack objects before use. Return early unless CONFIG_KASAN_GENERIC is enabled. Keep the mode check in the common helper so it covers both resume and bpf_throw(). Link: https://lore.kernel.org/20260916175113.1327454-1-ryabinin.a.a@gmail.com Fixes: 449e0b4ed5a1 ("fork: clean-up naming of vm_stack/vm_struct variables in vmap stacks code") Signed-off-by: Andrey Ryabinin Signed-off-by: Andrew Morton Reported-by: Shaobo Huang Closes: https://lore.kernel.org/all/20260806123020.90869-1-huangshaobo3@xiaomi.com/ Assisted-by: LLM Cc: Alexander Potapenko Cc: Andrey Konovalov Cc: David Hildenbrand Cc: Dmitry Vyukov Cc: Lorenzo Stoakes Cc: Vincenzo Frascino Cc: --- mm/kasan/common.c | 13 ++++++++++++- 1 file changed, 12 insertions(+), 1 deletion(-) diff --git a/mm/kasan/common.c b/mm/kasan/common.c index b7d05c2a6d93..7d21c4db68d2 100644 --- a/mm/kasan/common.c +++ b/mm/kasan/common.c @@ -114,12 +114,23 @@ void kasan_unpoison_task_stack(struct task_struct *task) /* Unpoison the stack for the current task beyond a watermark sp value. */ asmlinkage void kasan_unpoison_task_stack_below(const void *watermark) { + void *base; + + /* + * Only the generic mode needs this. In the tag-based mode the + * compiler fully initializes the shadow of stack variables on + * function entry, so stale tags left below the watermark are + * harmless. + */ + if (!IS_ENABLED(CONFIG_KASAN_GENERIC)) + return; + /* * Calculate the task stack base address. Avoid using 'current' * because this function is called by early resume code which hasn't * yet set up the percpu register (%gs). */ - void *base = (void *)((unsigned long)watermark & ~(THREAD_SIZE - 1)); + base = (void *)((unsigned long)watermark & ~(THREAD_SIZE - 1)); kasan_unpoison(base, watermark - base, false); } From 711d886fe76e28854814759f51ee175e279ef8c7 Mon Sep 17 00:00:00 2001 From: "David Hildenbrand (Arm)" Date: Fri, 18 Sep 2026 18:34:24 +0200 Subject: [PATCH 06/10] MAINTAINERS: split up MEMORY MANAGEMENT - MEMORY POLICY AND MIGRATION Patch series "MAINTAINERS: rework MEMORY MANAGEMENT - MEMORY POLICY". Let's rework MEMORY MANAGEMENT - MEMORY POLICY AND MIGRATION. As I can use some maintenance help in that area, add Gregory as a new co-maintainer for the split out MEMORY MANAGEMENT - NUMA PLACEMENT section. This patch (of 3): Let's split it up into MIGRATION and NUMA PLACEMENT. The latter is a better fitting description for mempolicy.c. Make a best guess about which pieces existing reviewers are interested in. Move the split sections to keep alphabetical order. Link: https://lore.kernel.org/20260918-maintainers-mempolicy-v1-1-9a94cac6d135@kernel.org Signed-off-by: David Hildenbrand (Arm) Signed-off-by: Andrew Morton Acked-by: Lorenzo Stoakes (ARM) Acked-by: Zi Yan Reviewed-by: Joshua Hahn Reviewed-by: SJ Park Acked-by: Vlastimil Babka (SUSE) Cc: Alistair Popple Cc: Byungchul Park Cc: Gregory Price Cc: "Huang, Ying" Cc: Liam R. Howlett Cc: Matthew Brost Cc: Michal Hocko Cc: Mike Rapoport Cc: Rakie Kim Cc: Suren Baghdasaryan --- MAINTAINERS | 62 ++++++++++++++++++++++++++++++++--------------------- 1 file changed, 37 insertions(+), 25 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index 140eafcbbd78..3f70a28df4b1 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -17208,31 +17208,6 @@ F: include/trace/events/ksm.h F: mm/ksm.c F: mm/mm_slot.h -MEMORY MANAGEMENT - MEMORY POLICY AND MIGRATION -M: Andrew Morton -M: David Hildenbrand -R: Zi Yan -R: Matthew Brost -R: Joshua Hahn -R: Rakie Kim -R: Byungchul Park -R: Gregory Price -R: Ying Huang -R: Alistair Popple -L: linux-mm@kvack.org -S: Maintained -W: http://www.linux-mm.org -T: git git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm -F: Documentation/ABI/testing/sysfs-kernel-mm-mempolicy -F: Documentation/ABI/testing/sysfs-kernel-mm-mempolicy-weighted-interleave -F: include/linux/mempolicy.h -F: include/uapi/linux/mempolicy.h -F: include/linux/migrate.h -F: include/linux/migrate_mode.h -F: mm/mempolicy.c -F: mm/migrate.c -F: mm/migrate_device.c - MEMORY MANAGEMENT - MGLRU (MULTI-GEN LRU) M: Andrew Morton R: Kairui Song @@ -17255,6 +17230,25 @@ F: include/linux/mmzone.h F: mm/vmscan.c F: mm/workingset.c +MEMORY MANAGEMENT - MIGRATION +M: Andrew Morton +M: David Hildenbrand +R: Zi Yan +R: Matthew Brost +R: Joshua Hahn +R: Byungchul Park +R: Gregory Price +R: Ying Huang +R: Alistair Popple +L: linux-mm@kvack.org +S: Maintained +W: http://www.linux-mm.org +T: git git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm +F: include/linux/migrate.h +F: include/linux/migrate_mode.h +F: mm/migrate.c +F: mm/migrate_device.c + MEMORY MANAGEMENT - MISC M: Andrew Morton M: David Hildenbrand @@ -17307,6 +17301,24 @@ F: mm/numa.c F: mm/numa_emulation.c F: mm/numa_memblks.c +MEMORY MANAGEMENT - NUMA PLACEMENT +M: Andrew Morton +M: David Hildenbrand +R: Zi Yan +R: Joshua Hahn +R: Rakie Kim +R: Gregory Price +R: Ying Huang +L: linux-mm@kvack.org +S: Maintained +W: http://www.linux-mm.org +T: git git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm +F: Documentation/ABI/testing/sysfs-kernel-mm-mempolicy +F: Documentation/ABI/testing/sysfs-kernel-mm-mempolicy-weighted-interleave +F: include/linux/mempolicy.h +F: include/uapi/linux/mempolicy.h +F: mm/mempolicy.c + MEMORY MANAGEMENT - OOM KILLER M: Michal Hocko R: David Rientjes From 4050a73a90f456887dc35d5bbfa4f4790eb5c2cf Mon Sep 17 00:00:00 2001 From: "David Hildenbrand (Arm)" Date: Fri, 18 Sep 2026 18:34:25 +0200 Subject: [PATCH 07/10] MAINTAINERS: move memory tiering under MEMORY MANAGEMENT - NUMA PLACEMENT NUMA PLACEMENT is a better place for memory tiering. My best guess is that existing MISC reviewers are not that interested in memory tiering, so don't carry any over. Link: https://lore.kernel.org/20260918-maintainers-mempolicy-v1-2-9a94cac6d135@kernel.org Signed-off-by: David Hildenbrand (Arm) Signed-off-by: Andrew Morton Acked-by: Lorenzo Stoakes (ARM) Acked-by: Zi Yan Reviewed-by: Joshua Hahn Reviewed-byt: SJ Park Acked-by: Vlastimil Babka (SUSE) Cc: Alistair Popple Cc: Byungchul Park Cc: Gregory Price Cc: "Huang, Ying" Cc: Liam R. Howlett Cc: Matthew Brost Cc: Michal Hocko Cc: Mike Rapoport Cc: Rakie Kim Cc: Suren Baghdasaryan --- MAINTAINERS | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index 3f70a28df4b1..d69f112e5abb 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -17264,7 +17264,6 @@ W: http://www.linux-mm.org T: git git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm F: Documentation/ABI/testing/sysfs-kernel-mm F: Documentation/ABI/testing/sysfs-kernel-mm-cma -F: Documentation/ABI/testing/sysfs-kernel-mm-memory-tiers F: Documentation/ABI/testing/sysfs-kernel-mm-numa F: Documentation/admin-guide/mm/ F: Documentation/mm/ @@ -17272,7 +17271,6 @@ F: drivers/char/mem.c F: include/linux/cma.h F: include/linux/dmapool.h F: include/linux/ioremap.h -F: include/linux/memory-tiers.h F: include/linux/page_idle.h F: mm/backing-dev.c F: mm/cma.c @@ -17284,7 +17282,6 @@ F: mm/early_ioremap.c F: mm/fadvise.c F: mm/ioremap.c F: mm/mapping_dirty_helpers.c -F: mm/memory-tiers.c F: mm/page_idle.c F: mm/pgalloc-track.h F: mm/process_vm_access.c @@ -17313,10 +17310,13 @@ L: linux-mm@kvack.org S: Maintained W: http://www.linux-mm.org T: git git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm +F: Documentation/ABI/testing/sysfs-kernel-mm-memory-tiers F: Documentation/ABI/testing/sysfs-kernel-mm-mempolicy F: Documentation/ABI/testing/sysfs-kernel-mm-mempolicy-weighted-interleave +F: include/linux/memory-tiers.h F: include/linux/mempolicy.h F: include/uapi/linux/mempolicy.h +F: mm/memory-tiers.c F: mm/mempolicy.c MEMORY MANAGEMENT - OOM KILLER From b3f0c1a4e41f356c3126a676ad55c0f6881e7514 Mon Sep 17 00:00:00 2001 From: "David Hildenbrand (Arm)" Date: Fri, 18 Sep 2026 18:34:26 +0200 Subject: [PATCH 08/10] MAINTAINERS: make Gregory a co-maintainer of MEMORY MANAGEMENT - NUMA PLACEMENT Gregory is extremely familiar with NUMA placement handling and volunteer to help co-maintain the numa placement bits. So add him as a co-maintainer. Link: https://lore.kernel.org/20260918-maintainers-mempolicy-v1-3-9a94cac6d135@kernel.org Signed-off-by: David Hildenbrand (Arm) Signed-off-by: Andrew Morton Acked-by: Lorenzo Stoakes (ARM) Acked-by: Gregory Price (Meta) Acked-by: Zi Yan Reviewed-by: Joshua Hahn Acked-by: SJ Park Acked-by: Vlastimil Babka (SUSE) Cc: Alistair Popple Cc: Byungchul Park Cc: "Huang, Ying" Cc: Liam R. Howlett Cc: Matthew Brost Cc: Michal Hocko Cc: Mike Rapoport Cc: Rakie Kim Cc: Suren Baghdasaryan --- MAINTAINERS | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/MAINTAINERS b/MAINTAINERS index d69f112e5abb..9fcda07a32a0 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -17301,10 +17301,10 @@ F: mm/numa_memblks.c MEMORY MANAGEMENT - NUMA PLACEMENT M: Andrew Morton M: David Hildenbrand +M: Gregory Price R: Zi Yan R: Joshua Hahn R: Rakie Kim -R: Gregory Price R: Ying Huang L: linux-mm@kvack.org S: Maintained From 6cc8f549f6888e36036ab14d84a8ec46b4a393c0 Mon Sep 17 00:00:00 2001 From: Joseph Qi Date: Wed, 23 Sep 2026 08:39:20 +0800 Subject: [PATCH 09/10] MAINTAINERS: add Heming Zhao as ocfs2 reviewer Heming Zhao has contributed ocfs2 a lot recent years, both as a author and reviewer. So add him as ocfs2 reviewer. Link: https://lore.kernel.org/20260923003920.2382398-1-joseph.qi@linux.alibaba.com Signed-off-by: Joseph Qi Signed-off-by: Andrew Morton Acked-by: Mark Fasheh Cc: Heming Zhao Cc: Joel Becker --- MAINTAINERS | 1 + 1 file changed, 1 insertion(+) diff --git a/MAINTAINERS b/MAINTAINERS index 9fcda07a32a0..23de9fc4c2a7 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -20568,6 +20568,7 @@ ORACLE CLUSTER FILESYSTEM 2 (OCFS2) M: Mark Fasheh M: Joel Becker M: Joseph Qi +R: Heming Zhao L: ocfs2-devel@lists.linux.dev S: Supported W: http://ocfs2.wiki.kernel.org From 976d5e0ddac885b0219252f004f6c561c344df9d Mon Sep 17 00:00:00 2001 From: "Lorenzo Stoakes (ARM)" Date: Wed, 23 Sep 2026 18:45:41 +0100 Subject: [PATCH 10/10] mm/vma: predicate setting mmap_prepare VMA fields on new vma alloc It only makes sense to manipulate VMA fields if a new VMA was allocated, rather than merged. VMA merging does not compare vm_ops or vm_private_data, so a merged VMA keeps its own, which is also what the legacy f_op->mmap path does since it never touches an existing VMA. Currently, these fields will get overwritten by whatever state is established in the mmap_prepare hook, and if the VMA was merged, vm_ops->mapped will not have been called, so this could destructively clear existing state without replacing it with anything valid. There is an implicit requirement that vm_private_data and vm_ops are fungible across VMAs which means that losing the 'new' state is fine. However in this case the 'old' state is being overwritten by potentially invalid 'new' state, so this must be rectified. Additionally constify have_mmap_prepare while here. All existing in-tree users either derive state from the file or are unmergeable due to VMA flags, so this has no direct impact. Link: https://lore.kernel.org/20260923-fix-mmap-prepare-overwrite-v1-1-3b3f1bfcdf5e@kernel.org Fixes: c84bf6dd2b83 ("mm: introduce new .mmap_prepare() file callback") Signed-off-by: Lorenzo Stoakes (ARM) Signed-off-by: Andrew Morton Reviewed-by: Suren Baghdasaryan Reviewed-by: Gregory Price (Meta) Acked-by: Zi Yan Acked-by: Vlastimil Babka (SUSE) Cc: Liam R. Howlett Cc: Jann Horn Cc: Pedro Falcato Cc: --- mm/vma.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/mm/vma.c b/mm/vma.c index 9f0a0acf694a..6cde67883fb0 100644 --- a/mm/vma.c +++ b/mm/vma.c @@ -2849,7 +2849,7 @@ static unsigned long __mmap_region(struct file *file, unsigned long addr, { struct mm_struct *mm = current->mm; struct vm_area_struct *vma = NULL; - bool have_mmap_prepare = file && file->f_op->mmap_prepare; + const bool have_mmap_prepare = file && file->f_op->mmap_prepare; VMA_ITERATOR(vmi, mm, addr); const pgoff_t anon_pgoff = addr >> PAGE_SHIFT; MMAP_STATE(map, mm, &vmi, addr, len, pgoff, anon_pgoff, vma_flags, file); @@ -2892,7 +2892,7 @@ static unsigned long __mmap_region(struct file *file, unsigned long addr, allocated_new = true; } - if (have_mmap_prepare) + if (have_mmap_prepare && allocated_new) set_vma_user_defined_fields(vma, &map); __mmap_complete(&map, vma);