Re: [PATCH 1/2] bpf: arena: fix use-after-free in VMA tracking on fork

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Critical] zap_pages() accesses user page tables locklessly, causing page table Use-After-Free during concurrent VMA teardown.
- [High] Silent allocation failure in arena_vm_open() leads to memory leak and physical page desynchronization.
--

commit 305653246e6ae24222d49bb8aa21f98a5bc22903
Author: Daniel Hodges <git@danielhodges.dev>
bpf: arena: fix use-after-free in VMA tracking on fork

This commit addresses a use-after-free by giving each vma its own vma_list
entry in arena_vm_open, rather than sharing a refcounted entry. It also
ensures arena_vm_close removes and frees the respective entry.

> diff --git a/kernel/bpf/arena.c b/kernel/bpf/arena.c
> --- a/kernel/bpf/arena.c
> +++ b/kernel/bpf/arena.c

[ ... ]

> @@ -336,9 +334,19 @@ static int remember_vma(struct bpf_arena *arena, struct vm_area_struct *vma)
>  
>  static void arena_vm_open(struct vm_area_struct *vma)
>  {
> -	struct vma_list *vml = vma->vm_private_data;
> +	struct bpf_map *map = vma->vm_file->private_data;
> +	struct bpf_arena *arena = container_of(map, struct bpf_arena, map);
> +	struct vma_list *vml;
>  
> -	refcount_inc(&vml->mmap_count);
> +	vml = kmalloc_obj(*vml);
> +	if (!vml) {
> +		vma->vm_private_data = NULL;
> +		return;
> +	}

Because vm_ops->open has a void return type, returning early here does not
abort the vma creation. The child vma will successfully map the arena memory
but remain omitted from arena->vma_list.

Later, when bpf_arena_free_pages() calls zap_pages(), it iterates only over
arena->vma_list. Does this omission cause the child process to retain valid
user-space ptes pointing to the old physical pages?

If so, this could prevent the physical pages from returning to the buddy
allocator, leaking the memory. It may also break shared memory coherency if
new physical pages are reallocated at the same virtual offset while the
child still accesses the old pages.

> +	vml->vma = vma;
> +	vma->vm_private_data = vml;
> +	guard(mutex)(&arena->lock);
> +	list_add(&vml->head, &arena->vma_list);
>  }

This is an existing issue not introduced by this patch, but zap_pages()
iterates over arena->vma_list and calls zap_vma_range() holding only
arena->lock.

The memory management subsystem requires mmap_lock or the per-vma lock to
be held for vma->vm_mm when traversing a vma's page tables. Concurrently,
processes may exit or unmap the arena. In the teardown sequence,
free_pgtables() unlinks and frees the pud, pmd, and pte pages before
remove_vma() invokes vma->vm_ops->close.

Could zap_pages() execute during this teardown window and attempt to walk
page tables that have already been freed, leading to a use-after-free on
the page directory and table pages themselves?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260513191322.21319-1-git@danielhodges.dev?part=1