Re: [RFC PATCH v2 02/13] mm: implement helpers for ANON_VMA_FRACTAL

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 4 potential issue(s) to consider:
- [High] `anon_node_alloc()` fails to take a reference on the intermediate `parent` node, leading to premature freeing and dangling parent pointers.
- [High] `anon_vma_fractal_init()` is defined but never called, leaving `anon_node_cachep` uninitialized.
- [Medium] The `anon_node` structure caches a raw pointer to an `mm_struct` without holding a reference, which can lead to a Use-After-Free.
- [Low] Unconditional access to conditionally compiled fields `rwsem` and `vm_lock_ref` breaks the build when `CONFIG_ANON_VMA_SHARED_SEMS` is enabled.
--

--- Patch [2]: [RFC PATCH v2 02/13] mm: implement helpers for ANON_VMA_FRACTAL ---
commit 353e80074df4a13790b7dd27f2e9eb1a62294b38
Author: tao <tao.wangtao@honor.com>

mm: implement helpers for ANON_VMA_FRACTAL
    
Implement basic helpers.

> diff --git a/mm/rmap.c b/mm/rmap.c
> index 9939400e77c79..54c5ccfee6813 100644
> --- a/mm/rmap.c
> +++ b/mm/rmap.c
[ ... ]
> @@ -558,6 +558,95 @@ void __init anon_vma_init(void)
>  			SLAB_PANIC|SLAB_ACCOUNT);
>  }
>  
> +#ifdef CONFIG_ANON_VMA_FRACTAL
> +
> +static struct kmem_cache *anon_node_cachep;
> +
> +static inline struct rw_semaphore *anon_node_rmap_sem(struct anon_node *node)
> +{
> +	return &node->root->rwsem;
> +}
> +
> +static inline atomic_t *anon_node_vm_lock_ref(struct anon_node *node)
> +{
> +	return &node->root->vm_lock_ref;
> +}
> +
> +static void anon_node_ctor(void *data)
> +{
> +	struct anon_node *anon_nod = data;
> +
> +	init_rwsem(&anon_nod->rwsem);
> +	atomic_set(&anon_nod->vm_lock_ref, 0);
> +	atomic_set(&anon_nod->refcount, 0);
> +}

[Severity: Low]
Does this cause a build failure when CONFIG_ANON_VMA_SHARED_SEMS is enabled?

The rwsem and vm_lock_ref fields in struct anon_node are conditionally
compiled out when this config is set, but they are accessed unconditionally
here in anon_node_ctor() and anon_node_rmap_sem().

> +
> +static inline void anon_vma_fractal_init(void)
> +{
> +	struct kmem_cache_args args = {
> +		.use_freeptr_offset = true,
> +		.freeptr_offset = offsetof(struct anon_node, fractal_list),
> +		.ctor = anon_node_ctor,
> +	};
> +
> +	anon_node_cachep = kmem_cache_create("anon_node",
> +			sizeof(struct anon_node), &args,
> +			SLAB_TYPESAFE_BY_RCU|SLAB_PANIC|SLAB_ACCOUNT);
> +}

[Severity: High]
Is anon_vma_fractal_init() ever called?

It doesn't appear to be hooked up to anon_vma_init() or anywhere else, which
would leave anon_node_cachep uninitialized and result in a null pointer
dereference crash on the first allocation.

[ ... ]
> +static inline struct anon_node *anon_node_alloc(struct vm_area_struct *vma,
> +		struct anon_node *parent, bool is_fork)
> +{
> +	struct anon_node *anon_nod;
> +
> +	anon_nod = kmem_cache_alloc(anon_node_cachep, GFP_KERNEL);
> +	if (!anon_nod)
> +		return NULL;
> +
> +	anon_nod->root = parent ? parent->root : anon_nod;
> +	anon_nod->parent = parent;
> +	atomic_set(&anon_nod->refcount, 1);
> +	anon_nod->depth = 0;
> +	if (parent) {
> +		get_anon_node(parent->root);
> +		anon_nod->depth = parent->depth + (1 << is_fork);
> +	}

[Severity: High]
Does this code leave the intermediate parent node vulnerable to being freed?

We assign anon_nod->parent = parent but only take a reference on parent->root.
If the intermediate parent is freed while this node is still alive,
anon_nod->parent becomes a dangling pointer.

> +	anon_nod->nr_children = 0;
> +	INIT_LIST_HEAD(&anon_nod->fractal_list);
> +	anon_nod->mm = vma->vm_mm;

[Severity: Medium]
Should we acquire a reference to the mm_struct using mmgrab() here?

A process exiting will free its mm_struct. If child processes keep the
parent's root anon_node alive via get_anon_node(parent->root), the
anon_node->mm pointer could become a dangling pointer, leading to a
use-after-free during lockless rmap walks.

> +	atomic_long_set(&anon_nod->rbc, vma_rmap_base(vma) + 1);
> +	return anon_nod;
> +}
> +
> +#endif

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