Re: [RFC PATCH v2 13/13] mm: Enable CONFIG_ANON_VMA_FRACTAL by default

[sashiko-bot@kernel.org]

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

Pre-existing issues:
- [High] RMAP walker Use-After-Free of `mm_struct` and VMA during VMA lock release due to skipped `mmgrab()` stabilization and flawed synchronization with `exit_mmap()`.
- [High] Enabling `CONFIG_ANON_VMA_SHARED_SEMS` exposes a Use-After-Free vulnerability because the dynamically allocated semaphores are freed without RCU protection but accessed under RCU.
--

--- Patch [13]: [RFC PATCH v2 13/13] mm: Enable CONFIG_ANON_VMA_FRACTAL by default ---
commit e2497626d5f9a80886b8bd9853568725462fff8d
Author: tao <tao.wangtao@honor.com>

mm: Enable CONFIG_ANON_VMA_FRACTAL by default

Everything is now in place to enable CONFIG_ANON_VMA_FRACTAL and
CONFIG_ANON_VMA_SHARED_SEMS for further testing.

> diff --git a/mm/Kconfig b/mm/Kconfig
> index 1a2c8085b12d5..7916c0127de0a 100644
> --- a/mm/Kconfig
> +++ b/mm/Kconfig
> @@ -1453,7 +1453,7 @@ config LOCK_MM_AND_FIND_VMA
>  
>  config ANON_VMA_FRACTAL
>  	bool "anon_vma fractal list"
> -	def_bool n
> +	def_bool y

[Severity: High]
This isn't a bug introduced by this patch, but enabling this feature by
default exposes a use-after-free race between the RMAP walker and
exit_mmap().

Looking at trylock_leaf_vma_rmap() in mm/rmap.c, it sets other_mm to NULL if
vma->vm_mm == mm, which skips the mmgrab() stabilization:

mm/rmap.c:trylock_leaf_vma_rmap() {
    ...
    *other_mm = (vma->vm_mm == mm) ? NULL : vma->vm_mm;
    ...
}

Then in folio_lock_anon_vma_read(), RCU protection is dropped while holding
an unpinned leaf_vma:

mm/rmap.c:folio_lock_anon_vma_read() {
    ...
    if (leaf_vma && !other_mm && folio_mapped(folio)) {
        rcu_read_unlock();
        return (void *)leaf_vma + ANON_RMAP_LEAF_VMA;
    }
    ...
}

Concurrently, if exit_mmap() acquires mmap_write_lock() but doesn't drain
per-VMA lock readers via vma_start_write(), it can free the VMA and the
unpinned mm_struct.

When the RMAP walker later calls anon_node_unlock_rmap(), it dereferences
the freed VMA and vm_mm to wake up writers:

mm/rmap.c:anon_node_unlock_rmap() {
    ...
    if (anon_rmap_is_leaf_vma(anon_nod)) {
        vma_refcount_put(anon_rmap_to_leaf_vma(anon_nod));
        return;
    }
    ...
}

Should the RMAP walker ensure the mm_struct is stabilized before dropping
RCU protection to prevent this?

>  	depends on MMU
>  	help
>  	  This option uses vma_rmap_base(vma) during rmap to compute the page
> @@ -1481,7 +1481,7 @@ config ANON_VMA_FRACTAL
>  
>  config ANON_VMA_SHARED_SEMS
>  	bool "anon_vma shared semaphores"
> -	def_bool n
> +	def_bool y

[Severity: High]
This isn't a bug introduced by this patch, but enabling ANON_VMA_SHARED_SEMS
by default exposes a use-after-free vulnerability with the dynamically
allocated semaphores.

In anon_vma_init() in mm/rmap.c, the slab cache for the shared semaphores is
created without SLAB_TYPESAFE_BY_RCU:

mm/rmap.c:anon_vma_init() {
    ...
    anon_sema_cachep = KMEM_CACHE(anon_semaphore, SLAB_PANIC|SLAB_ACCOUNT);
    ...
}

When the semaphore is freed in anon_root_sema_free(), it happens immediately
without an RCU grace period:

mm/rmap.c:anon_root_sema_free() {
    ...
    kmem_cache_free(anon_sema_cachep, root_sema);
    ...
}

However, folio_lock_anon_vma_read() locklessly accesses root->root_anon_sema
under rcu_read_lock() and attempts to modify it:

mm/rmap.c:folio_lock_anon_vma_read() {
    ...
    root_rwsem = anon_root_rmap_sem(root_anon_vma);
    if (down_read_trylock(root_rwsem)) {
    ...
}

Since the semaphore slab is not RCU-safe, the memory can be immediately
reclaimed by the buddy allocator or reallocated. 

Will down_read_trylock() end up modifying freed or completely unrelated
memory if a reclaim runs concurrently with an unmap?

>  	depends on ANON_VMA_FRACTAL
>  	help
>  	  As rmap operations rarely run concurrently, and fork/delete updates

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