Re: [PATCH 15/15] mm: enable CONFIG_ANON_VMA_LAZY on arm64 and x86_64

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 4 potential issue(s) to consider:

Pre-existing issues:
- [Critical] Dereferencing mm_struct in folio_resolve_anon_vma_lazy() causes a use-after-free because SLAB_TYPESAFE_BY_RCU allows the VMA to be recycled without pinning the new mm_struct.
- [Critical] Unbalanced refcount drop in vma_prepare_anon_vma() error path causes an underflow and premature freeing of the root anon_vma.
- [High] Toggling the sysctl anon_vma_lazy at runtime causes Use-After-Free and VM_BUG_ON_VMA crashes due to flawed structural state checks.
- [High] Unmapping the root of a split lazy anon VMA clears its anon_vma pointer, permanently breaking reverse mapping for folios in the remaining child VMAs.
--

commit 6ca138075f0d0c3a8eba3846297fc8cdfbebaa40
Author: tao <tao.wangtao@honor.com>

mm: enable CONFIG_ANON_VMA_LAZY on arm64 and x86_64

All prerequisites are in place, so enable CONFIG_ANON_VMA_LAZY for
arm64 and x86_64.

> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> index fe60738e5943b..9517883f0aaf2 100644
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
[ ... ]
> @@ -81,6 +81,7 @@ config ARM64
>  	select ARCH_SUPPORTS_NUMA_BALANCING
>  	select ARCH_SUPPORTS_PAGE_TABLE_CHECK
>  	select ARCH_SUPPORTS_PER_VMA_LOCK
> +	select ARCH_SUPPORTS_ANON_VMA_LAZY
>  	select ARCH_SUPPORTS_HUGE_PFNMAP if TRANSPARENT_HUGEPAGE
>  	select ARCH_SUPPORTS_RT
>  	select ARCH_SUPPORTS_SCHED_SMT
> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> index f3f7cb01d69d0..cc3430eaa7b41 100644
> --- a/arch/x86/Kconfig
> +++ b/arch/x86/Kconfig
[ ... ]
> @@ -28,6 +28,7 @@ config X86_64
>  	select ARCH_SUPPORTS_MSEAL_SYSTEM_MAPPINGS
>  	select ARCH_SUPPORTS_INT128 if CC_HAS_INT128
>  	select ARCH_SUPPORTS_PER_VMA_LOCK
> +	select ARCH_SUPPORTS_ANON_VMA_LAZY
>  	select ARCH_SUPPORTS_HUGE_PFNMAP if TRANSPARENT_HUGEPAGE
>  	select HAVE_ARCH_SOFT_DIRTY
>  	select MODULES_USE_ELF_RELA
> diff --git a/mm/rmap.c b/mm/rmap.c
> index b3bebb58e3597..4edf3311b1ae0 100644
> --- a/mm/rmap.c
> +++ b/mm/rmap.c
[ ... ]
> @@ -168,7 +168,7 @@ static struct kmem_cache *anon_vma_chain_cachep;
>   *        covering both regular anon_vma and lazy anon_vma mappings.
>   */
>  
> -bool anon_vma_lazy_enable;
> +bool anon_vma_lazy_enable = true;

[Severity: Critical]
This is a pre-existing issue, but enabling this by default exposes a potential
use-after-free when dereferencing the mm_struct in
folio_resolve_anon_vma_lazy().

During an RCU reverse mapping walk, folio_resolve_anon_vma_lazy() reads
mm = vma->vm_mm locklessly. Because VMAs are allocated with
SLAB_TYPESAFE_BY_RCU, the vma can be recycled and reallocated to a different
process during the walk.

The function calls vma_get() to increment the VMA refcount, but fails to pin
the foreign mm_struct via mmgrab(). If the foreign process exits concurrently,
its mm_struct is freed. The subsequent vma_lookup(mm, addr) dereferences
mm->mm_mt, resulting in a use-after-free.

Should the foreign mm_struct be stabilized with mmgrab() before performing
the lookup?

[Severity: Critical]
This is a pre-existing issue, but enabling this by default exposes an
unbalanced refcount drop in the vma_prepare_anon_vma() error path.

When attempting to upgrade a lazy anon_vma, a new anon_vma may be allocated.
If this thread loses a race and the VMA is already upgraded by another thread,
the likely(!vma->anon_vma || is_lazy) check evaluates to false, skipping
get_anon_vma(anon_vma->root).

However, the cleanup path unconditionally calls put_anon_vma(allocated).
Inside __put_anon_vma(), the root's refcount is decremented. Since it was
never incremented by this thread, this causes a refcount underflow and
premature freeing of the root anon_vma. This can lead to a use-after-free
for all other VMAs mapped to it.

Could the cleanup path be adjusted to only decrement the refcount if it was
successfully incremented?

[Severity: High]
This is a pre-existing issue, but enabling this by default exposes crashes
and memory issues if anon_vma_lazy_enable is toggled at runtime.

Disabling anon_vma_lazy_enabled() at runtime causes structural inconsistencies
for existing lazy VMAs. In anon_vma_fork(), the lazy fork path is skipped,
falling through to anon_vma_clone(), which calls vma_link_anon_vma_lazy_root().
This triggers VM_BUG_ON_VMA(vma->vm_mm != src->vm_mm, vma), which will crash
the kernel.

Furthermore, SWAP_VMG_TARGET_IF_DELETE_ANON_VMA_LAZY_ROOT() becomes a no-op,
meaning a pre-existing lazy root VMA being merged is deleted instead of
preserved. Reverse mapping walkers will later dereference this freed VMA via
folio->mapping, leading to a use-after-free.

Is it safe to toggle this sysctl at runtime while lazy VMAs already exist in
the system?

[Severity: High]
This is a pre-existing issue, but enabling this by default exposes a
regression when unmapping the root of a split lazy anon VMA.

When a lazy anon VMA is split, anon_vma_clone() links the new child VMA to
the root VMA by holding a reference to the root. If the root VMA is later
unmapped, unlink_anon_vmas() clears root_vma->anon_vma = NULL.

However, the child VMA remains alive, and its anonymous folios still point to
the root VMA via folio->mapping. During a reverse mapping walk,
folio_resolve_anon_vma_lazy() discovers !vma->anon_vma and aborts early.

This permanently breaks reverse mapping for the folios in the child VMA,
preventing them from being unmapped, migrated, or swapped out.

Does clearing root_vma->anon_vma need to account for surviving child VMAs to
avoid breaking reverse mapping?

>  #endif
>  
>  static inline struct anon_vma *anon_vma_alloc(void)

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260527110147.17815-1-tao.wangtao@honor.com?part=15