Re: [PATCH bpf v4 1/2] bpf: Fix use-after-free of arena VMA on fork

[Alexei Starovoitov]

On Mon, Apr 13, 2026 at 11:53 AM Alexei Starovoitov
<alexei.starovoitov@xxxxxxxxx> wrote:
>
> >
> > Thanks for the detailed review, really appreciate it.
> >
> > I traced through it with GDB + KASAN in QEMU. Here's what happens:
> >
> >   1. mmap → remember_vma()
> >      vml->vma = 0xffff88800abfe700, mmap_count  = 1
> >      now Parent VMA = 0xffff88800abfe700
> >   2. fork → arena_vm_open(child_vma)
> >      vml->vma = 0xffff88800abfe700 (unchanged), mmap_count  = 2
> >
> >   3. parent munmap → arena_vm_close(parent_vma)
> >      mmap_count  = 1
> >      vml->vma is now dangling
> >
> >   4. child bpf_arena_free_pages → zap_pages()
> >      reads vml->vma = 0xffff88800abfe700 → UAF
> >
> > The core issue is that arena_vm_open() never registers the child
> > VMA -- it only bumps the mmap_count . So vml->vma always points at
> > the parent, and dangles once the parent unmaps.
> >
> > What approach would you suggest for fixing this?
>
> I'm thinking to just do this:
>
> diff --git a/kernel/bpf/arena.c b/kernel/bpf/arena.c
> index f355cf1c1a16..a4f1df1bf0f4 100644
> --- a/kernel/bpf/arena.c
> +++ b/kernel/bpf/arena.c
> @@ -489,7 +489,7 @@ static int arena_map_mmap(struct bpf_map *map,
> struct vm_area_struct *vma)
>          * clears VM_MAYEXEC. Set VM_DONTEXPAND as well to avoid
>          * potential change of user_vm_start.
>          */
> -       vm_flags_set(vma, VM_DONTEXPAND);
> +       vm_flags_set(vma, VM_DONTEXPAND | VM_DONTCOPY);
>         vma->vm_ops = &arena_vm_ops;
>         return 0;
>  }

sent the fix:
https://lore.kernel.org/bpf/20260413194245.21449-1-alexei.starovoitov@xxxxxxxxx/