linux-stable.git, branch v6.18.51

Linux 6.18.51

2026-09-11T09:49:46+00:00

Link: https://lore.kernel.org/r/20260909134237.773280130@linuxfoundation.org
Tested-by: Brett A C Sheffield 
Tested-by: Pavel Machek (CIP) 
Tested-by: Florian Fainelli 
Tested-by: Wentao Guan 
Tested-by: Shuah Khan 
Tested-by: Ron Economos 
Tested-by: Peter Schneider 
Signed-off-by: Greg Kroah-Hartman

ksmbd: zero pipe read compound padding

2026-09-11T09:49:46+00:00

commit 73f860489e3be2245598d1819226304fc5b87291 upstream.

Compound response handling extends the last response iov to an eight-byte
boundary.

smb2_read_pipe() allocates only the payload size, so the alignment padding
can expose up to seven bytes of uninitialized kernel heap memory.

Allocate the aligned size and clear the unused tail before pinning the
response buffer.

Fixes: e2b76ab8b5c9 ("ksmbd: add support for read compound")
Reported-by: Cheryl Babcock 
Signed-off-by: Namjae Jeon 
Signed-off-by: Greg Kroah-Hartman

cifs: add fscache_resize_cookie() to cifs_setsize()

2026-09-11T09:49:46+00:00

commit fa724e235cfdb0fb0bb427d0f9dfe864ae27403e upstream.

Several code paths update the VFS inode size by calling
netfs_resize_file() and cifs_setsize(), but omit the corresponding
fscache_resize_cookie() call, leaving the fscache cookie out of sync
with the actual file size:

  - cifs_file_set_size() in inode.c: server-side truncation via setattr
  - cifs_do_truncate() in file.c: truncates to zero on O_TRUNC open
  - smb2_duplicate_extents() in smb2ops.c: file clone extending EOF
  - smb3_simple_falloc() in smb2ops.c: two branches that extend EOF
    via write-range and SMB2_set_eof respectively

Since every caller of cifs_setsize() must resize the fscache cookie,
add the call to cifs_setsize() itself, consistent with how
truncate_pagecache() is already consolidated there.

Fixes: 70431bfd825d ("cifs: Support fscache indexing rewrite")
Fixes: 93a43155127f ("cifs: Fix missing set of remote_i_size")
Fixes: 110fee6b9bb5 ("smb: client: fix missing timestamp updates with O_TRUNC")
Fixes: 7a06d3b816d7 ("smb/client: emulate small EOF-extending mode 0 fallocate ranges")
Cc: stable@vger.kernel.org
Cc: David Howells 
Cc: Paulo Alcantara 
Cc: Huiwen He 
Signed-off-by: Frank Sorenson 
Reviewed-by: Paulo Alcantara 
Signed-off-by: Steve French 
Signed-off-by: Greg Kroah-Hartman

mm/hugetlb_vmemmap: fix incorrect vmemmap restore in rollback

2026-09-11T09:49:46+00:00

commit c7bde43f6daf70e05a64fbca7efdf6fa93e057dc upstream.

vmemmap_restore_pte() rebuilds restored vmemmap pages from a tail-page
template derived from compound_head().  This is wrong when the current PTE
already maps a page whose contents are not tail-page metadata.

In the rollback path of vmemmap_remap_free(), the first restored PTE is
backed by vmemmap_head and contains head-page metadata.  Reconstructing
that page from a tail-page template overwrites the head-page state and
corrupts the restored vmemmap page.

Fix this by copying the full page from the page currently mapped by the
PTE.  Also pass vmemmap_tail to the rollback walk so only PTEs backed by
the shared tail page are restored, while the head PTE remains mapped to
vmemmap_head.  Add VM_WARN_ON_ONCE() checks for unexpected cases.

Link: https://lore.kernel.org/20260525025213.2229628-1-songmuchun@bytedance.com
Fixes: c0b495b91a47 ("mm/hugetlb: refactor code around vmemmap_walk")
Signed-off-by: Muchun Song 
Acked-by: Kiryl Shutsemau 
Acked-by: Oscar Salvador (SUSE) 
Cc: David Hildenbrand 
Cc: 
Signed-off-by: Andrew Morton 
Signed-off-by: Greg Kroah-Hartman

pidfs: protect PIDFD_GET_* ioctls() via ifdef

2026-09-11T09:49:46+00:00

commit 75ddaa4ddc86d31edb15e50152adf4ddee77a6ba upstream.

We originally protected PIDFD_GET__NAMESPACE ioctls() through
ifdefs and recent rework made it possible to drop them. There was an
oversight though. When the relevant namespace is turned off ns->ops will
be NULL so even though opening a file descriptor is perfectly legitimate
it would fail during inode eviction when the file was closed.

The simple fix would be to check ns->ops for NULL and continue allow to
retrieve namespace fds from pidfds but we don't allow retrieving them
when the relevant namespace type is turned off. So keep the
simplification but add the ifdefs back in.

Link: https://lore.kernel.org/20251222214907.GA189632@quark
Link: https://patch.msgid.link/20251224-ununterbrochen-gagen-ea949b83f8f2@brauner
Fixes: a71e4f103aed ("pidfs: simplify PIDFD_GET__NAMESPACE ioctls")
Tested-by: Brendan Jackman 
Tested-by: Eric Biggers 
Reported-by: Eric Biggers 
Signed-off-by: Christian Brauner 
Signed-off-by: Greg Kroah-Hartman

mm/huge_memory: use folio's memcg inside __folio_split()

2026-09-11T09:49:46+00:00

[ Upstream commit c299a2285d9d8bda4da024455de65e3d00de6f17 ]

Patch series "Honor XA_FLAGS_ACCOUNT in xas_split_alloc() and charge to
folio's memcg", v3.

__GFP_ACCOUNT is needed for xarray node allocation accounting when
XA_FLAGS_ACCOUNT is set. Commit 7b785645e8f13 ("mm: fix page cache
convergence regression") fixed a workingset regression with it.
xas_split_alloc() does not have it and needs to be fixed.

In addition, based on Sashiko's review[1] and Johannes' confirmation[2], to
charge the right memcg, folio's memcg needs to be active during folio
split. Add that before adding __GFP_ACCOUNT.

There is no workingset convergence regression related to missing
__GFP_ACCOUNT in xas_split_alloc() and the impact to userspace should be
minor.

This patch (of 2):

During a pagecache folio split, an xarray node allocation can happen and
needs to charge at folio's memcg instead of folio split invoker's memcg,
because for example folio split can happen during reclaim and reclaim's
active memcg might not be folio's memcg.  Switch to folio's memcg at the
beginning and switch back afterwards.

Link: https://lore.kernel.org/20260804-add-gfp_account-to-xas_split_alloc-v3-0-38cb3ff325c5@nvidia.com
Link: https://lore.kernel.org/20260804-add-gfp_account-to-xas_split_alloc-v3-1-38cb3ff325c5@nvidia.com
Link: https://sashiko.dev/#/patchset/20260727-add-gfp_account-to-xas_split_alloc-v1-1-9fae6bf64838%40nvidia.com?part=1 [1]
Link: https://lore.kernel.org/all/amtcBZ-_QVRgCd6b@cmpxchg.org/ [2]
Fixes: 6b24ca4a1a8d ("mm: Use multi-index entries in the page cache")
Signed-off-by: Zi Yan 
Suggested-by: Johannes Weiner 
Reviewed-by: Baolin Wang 
Acked-by: Lorenzo Stoakes (ARM) 
Acked-by: Johannes Weiner 
Cc: Barry Song 
Cc: David Hildenbrand 
Cc: Dev Jain 
Cc: Lance Yang 
Cc: Liam R. Howlett 
Cc: Matthew Wilcox (Oracle) 
Cc: Ryan Roberts 
Cc: William Kucharski 
Cc: 
Signed-off-by: Andrew Morton 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

migrate: replace RMP_ flags with TTU_ flags

2026-09-11T09:49:46+00:00

[ Upstream commit 832d95b5314eea558cf4cc9ca40db10122ce8f63 ]

Instead of translating between RMP_ and TTU_ flags, remove the RMP_ flags
and just use the TTU_ flag space; there's plenty available.

Possibly we should rename these to RMAP_ flags, and maybe even pass them
in through rmap_walk_arg, but that can be done later.

Link: https://lkml.kernel.org/r/20260109041345.3863089-3-willy@infradead.org
Signed-off-by: Matthew Wilcox (Oracle) 
Acked-by: David Hildenbrand (Red Hat) 
Reviewed-by: Lorenzo Stoakes 
Reviewed-by: Zi Yan 
Cc: Alistair Popple 
Cc: Byungchul Park 
Cc: Gregory Price 
Cc: Jann Horn 
Cc: Joshua Hahn 
Cc: Lance Yang 
Cc: Liam Howlett 
Cc: Matthew Brost 
Cc: Rakie Kim 
Cc: Rik van Riel 
Cc: Vlastimil Babka 
Cc: Ying Huang 
Signed-off-by: Andrew Morton 
Stable-dep-of: c299a2285d9d ("mm/huge_memory: use folio's memcg inside __folio_split()")
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

mm/huge_memory: replace can_split_folio() with direct refcount calculation

2026-09-11T09:49:45+00:00

[ Upstream commit 5842bcbfc316738cbfcbdb4def5a7592aa03ebf2 ]

can_split_folio() is just a refcount comparison, making sure only the
split caller holds an extra pin.  Open code it with
folio_expected_ref_count() != folio_ref_count() - 1.  For the extra_pins
used by folio_ref_freeze(), add folio_cache_ref_count() to calculate it.
Also replace folio_expected_ref_count() with folio_cache_ref_count() used
by folio_ref_unfreeze(), since they are returning the same values when a
folio is frozen and folio_cache_ref_count() does not have unnecessary
folio_mapcount() in its implementation.

Link: https://lkml.kernel.org/r/20251126210618.1971206-3-ziy@nvidia.com
Signed-off-by: Zi Yan 
Suggested-by: David Hildenbrand (Red Hat) 
Reviewed-by: Wei Yang 
Acked-by: David Hildenbrand (Red Hat) 
Cc: Balbir Singh 
Cc: Baolin Wang 
Cc: Barry Song 
Cc: Dev Jain 
Cc: Lance Yang 
Cc: Liam Howlett 
Cc: Lorenzo Stoakes 
Cc: Miaohe Lin 
Cc: Naoya Horiguchi 
Cc: Nico Pache 
Cc: Ryan Roberts 
Signed-off-by: Andrew Morton 
Stable-dep-of: c299a2285d9d ("mm/huge_memory: use folio's memcg inside __folio_split()")
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

mm/huge_memory: change folio_split_supported() to folio_check_splittable()

2026-09-11T09:49:45+00:00

[ Upstream commit bdd0d69a32c2aa6437d23e35acc705758b835a75 ]

Patch series "Improve folio split related functions", v4.

This patchset improves several folio split related functions to avoid
future misuse.  The changes are:

1. Consolidated folio splittable checks by moving truncated folio check,
   huge zero folio check, and writeback folio check into
   folio_split_supported(). Changed the function return type. Renamed it
   to folio_check_splittable() for clarification.

2. Replaced can_split_folio() with open coded folio_expected_ref_count()
   and folio_ref_count() and introduced folio_cache_ref_count().

3. Changed min_order_for_split() to always return an order.

4. Fixed folio split stats counting.

Motivation
==========
This is based on Wei's observation[1] and solves several potential
issues:
1. Dereferencing NULL folio->mapping in try_folio_split_to_order() if it
   is called on truncated folios.
2. Not handling of negative return value of min_order_for_split() in
   mm/memory-failure.c

There is no bug in the current code.

This patch (of 4):

folio_split_supported() used in try_folio_split_to_order() requires
folio->mapping to be non NULL, but current try_folio_split_to_order() does
not check it.  There is no issue in the current code, since
try_folio_split_to_order() is only used in truncate_inode_partial_folio(),
where folio->mapping is not NULL.

To prevent future misuse, move folio->mapping NULL check (i.e., folio is
truncated) into folio_split_supported().  Since folio->mapping NULL check
returns -EBUSY and folio_split_supported() == false means -EINVAL, change
folio_split_supported() return type from bool to int and return error
numbers accordingly.  Rename folio_split_supported() to
folio_check_splittable() to match the return type change.

While at it, move is_huge_zero_folio() check and folio_test_writeback()
check into folio_check_splittable() and add kernel-doc.

Remove all warnings inside folio_check_splittable() and give warnings
in __folio_split() instead, so that bool warns parameter can be removed.

Link: https://lkml.kernel.org/r/20251126210618.1971206-1-ziy@nvidia.com
Link: https://lkml.kernel.org/r/20251126210618.1971206-2-ziy@nvidia.com
Signed-off-by: Zi Yan 
Reviewed-by: Wei Yang 
Acked-by: Balbir Singh 
Acked-by: David Hildenbrand (Red Hat) 
Cc: Baolin Wang 
Cc: Barry Song 
Cc: Dev Jain 
Cc: Lance Yang 
Cc: Liam Howlett 
Cc: Lorenzo Stoakes 
Cc: Miaohe Lin 
Cc: Naoya Horiguchi 
Cc: Nico Pache 
Cc: Ryan Roberts 
Signed-off-by: Andrew Morton 
Stable-dep-of: c299a2285d9d ("mm/huge_memory: use folio's memcg inside __folio_split()")
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

mm: thp: use folio_batch to handle THP splitting in deferred_split_scan()

2026-09-11T09:49:45+00:00

[ Upstream commit 776bde7caf80f6af72b087cafe7d9f607b14716d ]

The maintenance of the folio->_deferred_list is intricate because it's
reused in a local list.

Here are some peculiarities:

   1) When a folio is removed from its split queue and added to a local
      on-stack list in deferred_split_scan(), the ->split_queue_len isn't
      updated, leading to an inconsistency between it and the actual
      number of folios in the split queue.

   2) When the folio is split via split_folio() later, it's removed from
      the local list while holding the split queue lock. At this time,
      the lock is not needed as it is not protecting anything.

   3) To handle the race condition with a third-party freeing or migrating
      the preceding folio, we must ensure there's always one safe (with
      raised refcount) folio before by delaying its folio_put(). More
      details can be found in commit e66f3185fa04 ("mm/thp: fix deferred
      split queue not partially_mapped"). It's rather tricky.

We can use the folio_batch infrastructure to handle this clearly.  In this
case, ->split_queue_len will be consistent with the real number of folios
in the split queue.  If list_empty(&folio->_deferred_list) returns false,
it's clear the folio must be in its split queue (not in a local list
anymore).

In the future, we will reparent LRU folios during memcg offline to
eliminate dying memory cgroups, which requires reparenting the split queue
to its parent first.  So this patch prepares for using
folio_split_queue_lock_irqsave() as the memcg may change then.

Link: https://lkml.kernel.org/r/59cb6b6fb5ffcff9d23b81890b252960139ad8e7.1762762324.git.zhengqi.arch@bytedance.com
Signed-off-by: Muchun Song 
Signed-off-by: Qi Zheng 
Reviewed-by: Zi Yan 
Acked-by: David Hildenbrand 
Acked-by: Shakeel Butt 
Reviewed-by: Wei Yang 
Reviewed-by: Harry Yoo 
Cc: Baolin Wang 
Cc: Barry Song 
Cc: Dev Jain 
Cc: Hugh Dickins 
Cc: Johannes Weiner 
Cc: Lance Yang 
Cc: Liam Howlett 
Cc: Lorenzo Stoakes 
Cc: Michal Hocko 
Cc: Muchun Song 
Cc: Nico Pache 
Cc: Roman Gushchin 
Cc: Ryan Roberts 
Signed-off-by: Andrew Morton 
Stable-dep-of: c299a2285d9d ("mm/huge_memory: use folio's memcg inside __folio_split()")
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman