Re: [PATCH 13/15] mm: support setup and upgrade of ANON_VMA_LAZY folios

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 6 potential issue(s) to consider:
- [Critical] Dereferencing `vma->vm_mm` before taking the VMA reference causes a Use-After-Free on the `mm_struct`.
- [Critical] Upgrading a VMA leaves dangling pointers in `folio->mapping`, leading to Use-After-Free.
- [High] rmap_walk_anon() silently aborts instead of retrying when a lazy mapping is concurrently upgraded.
- [High] Toggling the `anon_vma_lazy` sysctl at runtime causes `fork()` to crash with `VM_BUG_ON_VMA`.
- [High] Large anonymous folios spanning split VMAs break rmap traversal because only one VMA updates the folio mapping.
- [High] TOCTOU race in `__folio_rmap_sanity_checks()` causes a kernel panic when a folio mapping is concurrently upgraded.
--

commit a797e29fa9a2081d4af94616e5d30308d998bb4d
Author: tao <tao.wangtao@honor.com>
Subject: mm: support setup and upgrade of ANON_VMA_LAZY folios

This commit introduces ANON_VMA_LAZY folios setup and upgrade mechanisms
across mapping, duplicating, and rmap walk paths.

> rmap_walk_anon() detects ANON_VMA_LAZY upgrades and retries
> the walk to ensure the mapping is handled correctly.

[Severity: High]
The commit message mentions that rmap_walk_anon() retries the walk if it
detects an ANON_VMA_LAZY upgrade. Is this accurate?

It appears there is no retry loop. If folio_lock_anon_vma_lazy_read()
returns NULL because the mapping was upgraded concurrently,
rmap_walk_anon_lock() returns ANON_RMAP_NULL and rmap_walk_anon()
immediately aborts.

Could this cause reverse mapping operations like try_to_unmap() to silently
skip the folio, leading to memory leaks and failed migrations?

> diff --git a/include/linux/rmap.h b/include/linux/rmap.h
> --- a/include/linux/rmap.h
> +++ b/include/linux/rmap.h
> @@ -392,6 +392,14 @@ static __always_inline void __folio_rmap_sanity_checks(const struct folio *folio
>  		unsigned long mapping = (unsigned long)folio->mapping;
>  		struct anon_vma *anon_vma;
>  
> +		if (folio_test_anon_vma_lazy(folio)) {
> +			struct vm_area_struct *root_vma =
> +				(void *)(mapping - FOLIO_MAPPING_ANON_VMA_LAZY);
> +
> +			VM_WARN_ON_FOLIO(!rcuref_read(&root_vma->vm_rcuref), folio);
> +			return;
> +		}
> +
>  		anon_vma = (void *)(mapping - FOLIO_MAPPING_ANON);
>  		VM_WARN_ON_FOLIO(atomic_read(&anon_vma->refcount) == 0, folio);

[Severity: High]
Is there a TOCTOU race here when a folio mapping is concurrently upgraded?

The code reads folio->mapping into the local mapping variable, then
folio_test_anon_vma_lazy() re-reads folio->mapping. If the mapping is
upgraded to a regular anon_vma between these reads, the test returns false,
falling through to evaluate anon_vma using the first read which still has
the lazy tag.

This would yield an unaligned pointer (root_vma + 2), and dereferencing it
in atomic_read() would panic the kernel.

[ ... ]

> @@ -431,6 +439,31 @@ void hugetlb_add_anon_rmap(struct folio *, struct vm_area_struct *,
> +static inline void folio_upgrade_anon_vma_lazy(struct folio *folio,
> +					       struct vm_area_struct *vma)
> +{
> +	unsigned long anon_tree = (unsigned long)vma->anon_vma;
> +
> +	VM_BUG_ON_VMA(!anon_tree || !IS_ALIGNED(anon_tree, sizeof(long)), vma);

[Severity: High]
What happens if the anon_vma_lazy_enabled() sysctl is toggled to false at
runtime?

If anon_vma_fork() skips upgrading the parent VMA's lazy mapping, later in
fork(), copy_page_range() calls folio_try_dup_anon_rmap() which then
invokes folio_upgrade_anon_vma_lazy() here.

Since src_vma->anon_vma was never upgraded and holds a tagged
ANON_VMA_TREE_VMA pointer, wouldn't this IS_ALIGNED assertion fail and
panic the kernel?

> +	anon_tree = anon_tree + FOLIO_MAPPING_ANON;
> +	WRITE_ONCE(folio->mapping, (struct address_space *)anon_tree);
> +}

[Severity: High]
Can large anonymous folios spanning split VMAs break rmap traversal here?

When an ANON_VMA_LAZY VMA is split, a large folio can span both resulting
VMAs. During fork(), the first VMA is upgraded to a regular anon_vma and
updates folio->mapping. When the second VMA is processed,
folio_test_anon_vma_lazy() is already false, so the folio's mapping isn't
updated to reflect the second VMA.

Will future rmap walks traverse the first VMA but miss the second,
stranding PTEs and leaking memory?

[Severity: Critical]
Does upgrading a VMA leave dangling pointers in folio->mapping?

When a lazy VMA is upgraded to a regular anon_vma (for example, via
vma_upgrade_anon_vma_lazy() during khugepaged operations or mprotect), it
seems the VMA drops its reference to root_vma, but the page tables aren't
walked to update folio->mapping for existing folios.

These folios would retain the old root_vma + FOLIO_MAPPING_ANON_VMA_LAZY
pointer. When the root_vma is eventually freed, could any rmap walk on
these folios dereference the dangling pointer, causing a use-after-free on
the freed VMA slab object?

[Severity: Critical]
While not explicitly in the provided diff context, can dereferencing
vma->vm_mm before taking the VMA reference cause a use-after-free on the
mm_struct?

In folio_resolve_anon_vma_lazy(), the code reads mm = vma->vm_mm before
calling vma_get(anon_lazy_root). Because the VMA is allocated from a
SLAB_TYPESAFE_BY_RCU cache, it can be freed and recycled to a completely
different process concurrently.

The read mm pointer may point to a freed mm_struct. Calling
vma_lookup(mm, addr) subsequently dereferences this stale mm pointer,
leading to a use-after-free.

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