BPF List
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Kumar Kartikeya Dwivedi" <memxor@gmail.com>
Cc: bpf@vger.kernel.org
Subject: Re: [RFC PATCH bpf-next v1 03/16] bpf: Back typed arena chunks with scratch on demand
Date: Sat, 26 Sep 2026 23:56:42 +0000	[thread overview]
Message-ID: <20260926235642.9D8411F000FF@smtp.kernel.org> (raw)
In-Reply-To: <20260926233503.3114147-4-memxor@gmail.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Critical] bpf: Use-After-Free due to missing PTE cleanup in typed_arena_teardown_cb()
--

commit 5ad8213f9e65607de0b6ea3647cc93fae67f349a
Author: Kumar Kartikeya Dwivedi <memxor@gmail.com>

bpf: Back typed arena chunks with scratch on demand

This patch introduces demand-paging for typed BPF arenas, where unbacked
pages fault and are populated with scratch memory. It handles the fault
recovery, marks chunks in a bitmap, and adds allocation and freeing
mechanisms for these chunks during the map's lifecycle.

> diff --git a/kernel/bpf/arena.c b/kernel/bpf/arena.c
> index 9cd1b1ce434c4..c757c19323602 100644
> --- a/kernel/bpf/arena.c
> +++ b/kernel/bpf/arena.c

[ ... ]

> @@ -371,7 +396,7 @@ static int typed_arena_teardown_cb(pte_t *ptep, unsigned long addr, void *data)
>  
>  	if ((addr - (unsigned long)ta->base) & (bpf_typed_arena_chunk(ta) - 1))
>  		return 0;
> -	if (!pte_present(pte))
> +	if (!pte_present(pte) || pte_page(pte) == typed_arena_scratch_page(ta, addr))
>  		return 0;
>  	typed_arena_free_objects(ta, (void *)addr);
>  	__free_pages(pte_page(pte), typed_arena_chunk_order(ta));

[Severity: Critical]
Does this leave the kernel leaf PTEs pointing to freed memory?

This callback frees the physical pages for allocated chunks using
__free_pages(), but it doesn't appear to clear the PTEs using pte_clear()
or ptep_get_and_clear().

If a typed arena is destroyed (for example, if a BPF program load fails
after allocation), bpf_typed_arena_put() calls typed_arena_free(), which
then uses this callback. The underlying memory is freed, but the page
tables remain populated with valid mappings.

Because typed_arena_find_slice() searches for and reuses freed address
gaps, a subsequently loaded BPF program could allocate an arena of the
same size, inherit the same virtual address slice, and access these stale
PTEs to manipulate the freed memory.

> @@ -383,6 +408,10 @@ static void typed_arena_free(struct bpf_arena *arena, struct bpf_typed_arena *ta
>  	WRITE_ONCE(arena->typed_arena_mem, arena->typed_arena_mem - typed_arena_static_mem(ta));
>  	apply_to_existing_page_range(&init_mm, (unsigned long)ta->base, bpf_typed_arena_size(ta),
>  				     typed_arena_teardown_cb, ta);
> +	/* Programs may have stored kptrs into the dummy objects. */
> +	typed_arena_free_objects(ta, ta->scratch);
> +	vfree(ta->scratch);

[Severity: Critical]
Could this similarly leave stale mappings to freed scratch space?

The scratch pages are freed via vfree(), but the aliased PTEs within the
arena's kernel VM area that point to these scratch pages are never cleared
during the teardown process.

> +	kfree(ta->scratch_pages);
>  	bitmap_free(ta->chunks);
>  	bitmap_free(ta->pending);
>  	btf_put(ta->btf);

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260926233503.3114147-1-memxor@gmail.com?part=3

  reply	other threads:[~2026-09-26 23:56 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-26 23:34 [RFC PATCH bpf-next v1 00/16] BPF typed arenas Kumar Kartikeya Dwivedi
2026-09-26 23:34 ` [RFC PATCH bpf-next v1 01/16] mm/vmalloc: Add get_vm_area_align() Kumar Kartikeya Dwivedi
2026-09-26 23:42   ` sashiko-bot
2026-09-26 23:34 ` [RFC PATCH bpf-next v1 02/16] bpf: Introduce BPF typed arenas Kumar Kartikeya Dwivedi
2026-09-26 23:34 ` [RFC PATCH bpf-next v1 03/16] bpf: Back typed arena chunks with scratch on demand Kumar Kartikeya Dwivedi
2026-09-26 23:56   ` sashiko-bot [this message]
2026-09-26 23:34 ` [RFC PATCH bpf-next v1 04/16] bpf: Add the typed_arena_cast instruction Kumar Kartikeya Dwivedi
2026-09-26 23:55   ` sashiko-bot
2026-09-26 23:34 ` [RFC PATCH bpf-next v1 05/16] bpf: Allow scalar and atomic access to typed arena objects Kumar Kartikeya Dwivedi
2026-09-26 23:34 ` [RFC PATCH bpf-next v1 06/16] bpf: Support special fields in " Kumar Kartikeya Dwivedi
2026-09-26 23:59   ` sashiko-bot
2026-09-26 23:34 ` [RFC PATCH bpf-next v1 07/16] bpf: Trust typed pointer fields of " Kumar Kartikeya Dwivedi
2026-09-27  0:03   ` sashiko-bot
2026-09-26 23:34 ` [RFC PATCH bpf-next v1 08/16] bpf: Canonicalize loaded typed arena pointers where they are used Kumar Kartikeya Dwivedi
2026-09-26 23:34 ` [RFC PATCH bpf-next v1 09/16] bpf: Add typed arena page allocation and release kfuncs Kumar Kartikeya Dwivedi
2026-09-26 23:55   ` sashiko-bot
2026-09-26 23:34 ` [RFC PATCH bpf-next v1 10/16] bpf: Let typed_arena_cast copy pointers the verifier already trusts Kumar Kartikeya Dwivedi
2026-09-26 23:49   ` sashiko-bot
2026-09-26 23:34 ` [RFC PATCH bpf-next v1 11/16] libbpf: Support the typed_arena_cast instruction Kumar Kartikeya Dwivedi
2026-09-26 23:34 ` [RFC PATCH bpf-next v1 12/16] selftests/bpf: Build BPF objects with compiler-inserted typed arena casts Kumar Kartikeya Dwivedi
2026-09-26 23:46   ` sashiko-bot
2026-09-26 23:34 ` [RFC PATCH bpf-next v1 13/16] selftests/bpf: Test typed arena casts and registration Kumar Kartikeya Dwivedi
2026-09-26 23:34 ` [RFC PATCH bpf-next v1 14/16] selftests/bpf: Test typed arena object access, kptrs and typed pointer fields Kumar Kartikeya Dwivedi
2026-09-26 23:34 ` [RFC PATCH bpf-next v1 15/16] selftests/bpf: Test typed arena page allocation and release Kumar Kartikeya Dwivedi
2026-09-26 23:46   ` sashiko-bot
2026-09-26 23:34 ` [RFC PATCH bpf-next v1 16/16] selftests/bpf: Exercise typed arenas at run time Kumar Kartikeya Dwivedi
2026-09-26 23:50   ` sashiko-bot

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260926235642.9D8411F000FF@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=memxor@gmail.com \
    --cc=sashiko-reviews@lists.linux.dev \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox