linux.git/mm, branch v7.2-rc7

Merge tag 'mm-hotfixes-stable-2026-08-06-18-44' of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm

2026-08-07T03:29:38+00:00

Pull MM fixes from Andrew Morton:
 "17 hotfixes.  15 are cc:stable.  16 are for MM.

  There's a patch series from Lorenzo "mm: fix UAF caused by race
  between ptdump and vmap pgtable freeing" which addresses a quite old
  bug in the ptdump code.

  And another series also from Lorenzo which fixes a four year old bug
  in the huge_zero_folio handling.

  A series from SJ fixes a few possible divide-by-zero issues which
  Sashiko sniffed out. And a series which fixes handling of the
  commit_inputs parameters.

  The remainder are singletons, please see their changelogs for details"

* tag 'mm-hotfixes-stable-2026-08-06-18-44' of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm:
  mm/damon: adjust isolated pages stat for DAMOS_MIGRATE_{HOT,COLD}
  mm/damon/ops-common: putback folios on invalid migrate nid
  mm/huge_memory: initialise workingset state before folio split
  mm/page_table_check: skip special zero mappings
  mm/damon/lru_sort: skip damon_call() if ctx has not started
  mm/damon/reclaim: skip damon_call() if ctx has not started
  mm/damon/lru_sort: error out for >10000 active_mem_bp
  samples/damon/mtier: error out for zero quota goal target values
  mailmap: map old addresses to Danila Tikhonov
  mm/huge_memory: separate out CONFIG_PERSISTENT_HUGE_ZERO_FOLIO logic
  mm/huge_memory: fix huge_zero_pfn race
  MAINTAINERS: update address for Brendan Jackman
  mm/filemap: __filemap_add_folio() restore index before retrying
  microblaze: restore the page alignment of swapper_pg_dir
  arm64: remove redundant concurrent ptdump UAF mitigation
  mm/ptdump: always stabilise against page table freeing using init_mm
  mm/vmalloc: acquire init_mm lock on huge vmap to avoid ptdump UAF

mm: fix incorrect flush address in direct page table reclaim

2026-08-05T15:00:25+00:00

When zap_pte_range reclaims a page table, it does:

    pte_free_tlb(tlb, pmd_pgtable(pmdval), addr);

and this is unconditionally wrong: if this code executes, addr *always*
points one past the end of the range covered by the table.  The addr
parameter is used to flush the TLB (really the paging-structure-cache)
to drop references to the to-be-freed table, and any architecture that
cares about the parameter will flush the wrong address.  (But they'll
still free the correct page).

I think it's worth contemplating why the kernel works at all.

If we hit the offending line of code, we will first clear the PMD entry
(line 1954, zap_empty_pte_table), then we will issue pending flushes if
force_flush is set (tlb_flush_mmu_tlbonly(tlb)), then we will skip the
retry on line 1979 (phew!), and then we will do the offending
pte_free_tlb call.  *Or* we will clear the PMD entry immediately before
pte_free_tlb (line 1983, zap_pte_table_if_empty).

If we have any pending flushes (i.e. we actually zapped any last-level
entries) at the time we clear the PMD entry, then the flush really ought
to flush all references to the table (Linus certainly seems to think it
will on all architectures [0]).

The condition under which we have no accumulated flushes at the time of
the clear is very complex (the whole zap_pte_range function has absurdly
complex control flow).  If we do hit the bad case, then we will end up
clearing the PMD entry after the last time the range is flushed, and any
CPU is free to cache a reference to the (empty) page table.  If this
happens due to an ordinary read or write, it would segfault, so it would
be rare.  But the cache could be speculatively filled as well.  Then
we'll flush the wrong address and then free and possibly reuse the
table.

On x86, even flushing the wrong address works on non-KPTI Intel systems
because INVLPG flushes *all* paging-structure-caches, not just the ones
for the target address.  But INVPCID does not, and flush_tlb_one_user
will use INVPCID if it's available.  And then we're toast.  AMD systems
are more susceptible: we set the EFER.TCE bit, which makes even INVLPG
only flush the target address.

I think this might fix an issue in ripgrep reported here:
https://github.com/BurntSushi/ripgrep/issues/3494

[0] https://lore.kernel.org/all/CA+55aFzBggoXtNXQeng5d_mRoDnaMBE5Y+URs+PHR67nUpMtaw@mail.gmail.com/T/#u

Signed-off-by: Andy Lutomirski 
Fixes: 4c640eb4181c ("mm: move pte table reclaim code to memory.c")
Cc: Liam Howlett 
Cc: Liam R. Howlett 
Cc: Lorenzo Stoakes 
Cc: Mike Rapoport 
Cc: Suren Baghdasaryan 
Cc: stable@vger.kernel.org
Acked-by: Vlastimil Babka (SUSE) 
Acked-by: David Hildenbrand (Arm) 
Acked-by: Michal Hocko 
Acked-by: Qi Zheng 
Signed-off-by: Linus Torvalds

mm/damon: adjust isolated pages stat for DAMOS_MIGRATE_{HOT,COLD}

2026-08-05T03:02:04+00:00

Callers of migrate_pages() should adjust NR_MIGRATED_{ANON,FILE} for
isolations and putback of the folios.  That for migration succeeded folios
is done by migrate_pages(), in migrate_folio_done().  That for MR_DEMOTION
reason is an exception though.

DAMOS_MIGRATE_{HOT,COLD} call migrate_pages() but mistakenly not doing the
stat adjustment.  As a result, use of DAMOS_MIGRATE_{HOT,COLD} could
corrupt the stat.  It could confuse too_many_isolated(), make compaction
and reclaim to behave in unexpected ways.  The stat corruption can be
reproduced and confirmed using DAMON user-space tool [1] on NUMA systems,
like below.

    $ numactl --hardware
    available: 2 nodes (0-1)
    [...]
    $ sudo ./damo start --damos_action migrate_hot 1
    $ sudo cat /proc/sys/vm/stat_refresh
    $ sudo dmesg
    [...]
    [   80.215554] vmstat_refresh: nr_isolated_anon -5578
    [   80.216842] vmstat_refresh: nr_isolated_file -34400

This issue was discovered [2] by Sashiko.

Link: https://lore.kernel.org/20260728140404.94476-1-sj@kernel.org
Link: https://github.com/damonitor/damo [1]
Link: https://lore.kernel.org/20260726164356.87940-1-sj@kernel.org [2]
Fixes: b51820ebea65 ("mm/damon/paddr: introduce DAMOS_MIGRATE_COLD action for demotion")
Signed-off-by: SJ Park 
Cc: Honggyu Kim 
Cc: Hyeongtak Ji 
Cc:  # 6.11.x
Signed-off-by: Andrew Morton

mm/damon/ops-common: putback folios on invalid migrate nid

2026-08-05T03:02:04+00:00

damon_pa_migrate() and damos_va_migrate() isolate folios into a local list
and then call damon_migrate_pages().  When target_nid is invalid
(including the scheme default NUMA_NO_NODE / -1), damon_migrate_pages()
returns early without putting the folios back to the LRU.

Callers then discard the list head while those folios remain isolated with
an extra reference taken by folio_isolate_lru().  The pages stay off the
LRU for as long as the mapping exists (anon active+inactive counts drop
while RSS does not), and the leftover references can pin the pages after
the mapping is gone.

Put the folios back on the invalid-nid path so ignored migration requests
still return them to the LRU.

Link: https://lore.kernel.org/20260726014815.1280757-1-dayou5941@163.com
Fixes: 7e6c3130690a ("mm/damon/ops-common: ignore migration request to invalid nodes")
Assisted-by: Cursor:grok-4.5
Reviewed-by: SJ Park 
Signed-off-by: liyouhong 
Cc: 
Signed-off-by: Andrew Morton

mm/huge_memory: initialise workingset state before folio split

2026-08-05T03:02:03+00:00

xas_try_split() adds __GFP_ACCOUNT for page-cache xa_nodes, but
__folio_split() leaves the xa_state's xa_lru unset.  That lets a live,
memcg-charged xa_node exist without being linked into the mapping's
shadow_nodes list_lru; when reclaim later walks the list_lru it trips
VM_WARN_ON(!css_is_dying()).

Use mapping_set_update() to install both the workingset update callback
and the shadow_nodes list_lru on the xa_state.

Link: https://lore.kernel.org/20260725101419.3938406-1-matt@readmodwrite.com
Fixes: 58729c04cf10 ("mm/huge_memory: add buddy allocator like (non-uniform) folio_split()")
Signed-off-by: Matt Fleming 
Reported-by: syzbot+c5b060ce82921a2fd500@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=c5b060ce82921a2fd500
Reviewed-by: Zi Yan 
Acked-by: David Hildenbrand (Arm) 
Cc: Baolin Wang 
Cc: Barry Song 
Cc: Dave Chinner 
Cc: Dev Jain 
Cc: Kairui Song 
Cc: Lance Yang 
Cc: Liam Howlett 
Cc: Lorenzo Stoakes 
Cc: Matthew Wilcox (Oracle) 
Cc: Muchun Song 
Cc: Nico Pache 
Cc: Roman Gushchin 
Cc: Ryan Roberts 
Cc: Shakeel Butt 
Cc: 
Signed-off-by: Andrew Morton

mm/page_table_check: skip special zero mappings

2026-08-05T03:02:03+00:00

page_table_check_set() and page_table_check_clear() account mappings based
on PageAnon().  Shared zero-page PTEs and huge zero PMDs are special
mappings, but page_table_check can still account them as file-backed
pages.

An unprivileged process can populate enough zero mappings to overflow
file_map_count and hit the existing BUG_ON().  The PTE path can do this
with the shared zero page, and the PMD path can do the same with huge zero
mappings.

Skip special zero mappings in the user page-table accounting paths.  Keep
the PTE-side pte_special() check, and identify huge zero PMDs from the
mapped folio instead of pmd_special().  That covers architectures where
pmd_special() is a no-op without adding huge_zero_pfn checks to the
generic counter helpers.

Link: https://lore.kernel.org/cover.1784717203.git.zhilinz@nebusec.ai
Link: https://lore.kernel.org/e94478e4fb7912fb7e8ebebed5ce85d00dc9a69d.1784717203.git.zhilinz@nebusec.ai
Fixes: df4e817b7108 ("mm: page table check")
Signed-off-by: Zhiling Zou 
Signed-off-by: Ren Wei 
Reported-by: Vega 
Cc: Pasha Tatashin 
Assisted-by: Codex:gpt-5.4
Cc: 
Signed-off-by: Andrew Morton

mm/damon/lru_sort: skip damon_call() if ctx has not started

2026-08-05T03:02:03+00:00

DAMON_LRU_SORT calls damon_call() for commit_inputs parameter user input
if the DAMON context is initialized.  The context could be initialized,
but not yet successfully started.  In the case, damon_call() could
indefinitely hang.  Read the comment on damon_call() for more detail.  Fix
the problem by memorizing if the DAMON context has ever successfully
started, and skip damon_call() if it has not.

This issue can easily be reproduced by writing Y to the commit_inputs
parameter file on a system that DAMON_LRU_SORT has not turned on before.

Link: https://lore.kernel.org/20260803134646.16640-3-sj@kernel.org
Fixes: de3c60e1c831 ("mm/damon: add synchronous commit for commit_inputs")
Signed-off-by: SJ Park 
Cc: Liew Rui Yan 
Cc:  # 7.2.x
Signed-off-by: Andrew Morton

mm/damon/reclaim: skip damon_call() if ctx has not started

2026-08-05T03:02:03+00:00

Patch series "mm/damon/{reclaim,lru_sort}: fix commit_inputs infinite
hang".

Writing 'Y' to commit_inputs parameters of DAMON_RECLAIM and
DAMON_LRU_SORT before the modules were ever turned on causes infinite
hang.  Fix those.

The issue was discovered [1] by Sashiko.


This patch (of 2):

DAMON_RECLAIM calls damon_call() for commit_inputs parameter user input if
the DAMON context is initialized.  The context could be initialized, but
not yet successfully started.  In the case, damon_call() could
indefinitely hang.  Read the comment on damon_call() for more detail.  Fix
the problem by memorizing if the DAMON context has ever successfully
started, and skip damon_call() if it has not.

This issue can easily be reproduced by writing Y to commit_inputs on a
system that DAMON_RECLAIM was not turned on before.

Link: https://lore.kernel.org/20260803134646.16640-1-sj@kernel.org
Link: https://lore.kernel.org/20260803134646.16640-2-sj@kernel.org
Link: https://lore.kernel.org/20260802173021.762-1-sj@kernel.org [1]
Fixes: de3c60e1c831 ("mm/damon: add synchronous commit for commit_inputs")
Signed-off-by: SJ Park 
Cc: Liew Rui Yan 
Cc:  # 7.2.x
Signed-off-by: Andrew Morton

mm/damon/lru_sort: error out for >10000 active_mem_bp

2026-08-05T03:02:02+00:00

damos_quota_score() can trigger division by zero if the target value is
zero.  DAMON_LRU_SORT lets users set the target value for the hot memory
scheme via active_mem_bp parameter.  It avoids setting it as the target
value if the parameter value is zero.  However, it also sets the cold
memory scheme with a target value that is calculated as '10000 -
active_mem_bp + 2'.  Hence, if a user sets active_mem_bp 10002, the cold
memory scheme's quota goal target value can be zero.  As a result,
division by zero can be triggered.  Fix by returning an error when the
user tries to start DAMON with >10000 active_mem_bp parameter value.

It makes no sense to set active_mem_bp with 10002.  It also requires
module parameters write permission to reproduce the issue.  That said, the
consequence is quite bad.

One reliable way to reproduce the issue is like below:

    # cd /sys/module/damon_lru_sort/parameters
    # echo 1000 > wmarks_high
    # echo 995 > wmarks_mid
    # echo 0 > wmarks_low
    # echo 10002 > active_mem_bp
    # echo Y > enabled
    # dmesg -w
    [...]
    [  597.421247] Oops: divide error: 0000 [#1] SMP NOPTI
    [  597.428848] RIP: 0010:damos_quota_score+0x6f/0x480

This issue was discovered [1] by Sashiko.

Link: https://lore.kernel.org/20260803134034.15217-3-sj@kernel.org
Link: https://lore.kernel.org/20260801213028.5127-1-sj@kernel.org [1]
Fixes: 40d98d31cd70 ("mm/damon/lru_sort: support active:inactive memory ratio based auto-tuning")
Signed-off-by: SJ Park 
Cc:  # 7.0.x
Signed-off-by: Andrew Morton

mm/huge_memory: separate out CONFIG_PERSISTENT_HUGE_ZERO_FOLIO logic

2026-08-05T03:02:02+00:00

Rather than mixing the refcounted and non-refcounted
CONFIG_PERSISTENT_HUGE_ZERO_FOLIO logic, separate the two out cleanly so
it is clear what happens when this configuration option is set and what
happens when it is not.

Introduce HUGE_ZERO_UNSET_PFN to abstract the ~0UL assignment, only
introduce the refcount, lock and shrinker if
!CONFIG_PERSISTENT_HUGE_ZERO_FOLIO, abstract initialisation and teardown,
abstract the huge zero folio allocation from refcounting.

Also change a BUG_ON() to WARN_ON_ONCE() while we're at it.

No functional change intended.

Link: https://lore.kernel.org/20260730-fix-refcounted-huge-zero-v2-2-c5d8a41b317f@kernel.org
Signed-off-by: Lorenzo Stoakes (ARM) 
Fixes: 3b77e8c8cde5 ("mm/thp: make is_huge_zero_pmd() safe and quicker")
Cc: Baolin Wang 
Cc: Barry Song 
Cc: David Hildenbrand (Arm) 
Cc: Dev Jain 
Cc: Hannes Reinecke 
Cc: Hengbin Zhang 
Cc: Hugh Dickins 
Cc: Kiryl Shutsemau 
Cc: Lance Yang 
Cc: Liam R. Howlett 
Cc: Nico Pache 
Cc: Pankaj Raghav 
Cc: Ryan Roberts 
Cc: Yang Shi 
Cc: Zi Yan 
Cc: 
Signed-off-by: Andrew Morton