Re: [PATCH bpf-next v4 3/7] bpf: Add sleepable arena page allocation path

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] bpf: CPU lockups and memory pressure due to massive page allocations before range validation
--

commit 0ff0c13da92aa5b627b22373d01f9a6a0085c43f
Author: Emil Tsalapatis <emil@etsalapatis.com>

bpf: Add sleepable arena page allocation path

This commit modifies the BPF arena allocator to allocate physical pages
outside the spinlock. This allows sleepable BPF programs to use the
blocking allocator slow path when under memory pressure.

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

[ ... ]

> @@ -747,8 +769,12 @@ static long arena_alloc_pages(struct bpf_arena *arena, long uaddr, long page_cnt
>  			/* requested address will be outside of user VMA */
>  			return 0;
>  	}
> -
>  	bpf_map_memcg_enter(&arena->map, &old_memcg, &new_memcg);
> +
> +	ret = bpf_alloc_pages(node_id, page_cnt, &pages, sleepable);
> +	if (ret)
> +		goto out_memcg;
> +

[Severity: High]
Could this early allocation trigger system instability or CPU lockups under
pressure? 

By moving bpf_alloc_pages() before the arena_adjust_tree() check, a BPF
program can request a huge page_cnt (up to the entire arena size). Because
the physical pages are allocated before we verify if the requested virtual
address range is actually available in the range tree, this could result in
massive physical memory allocations and blocking reclaims.

If the requested virtual range is already occupied, the allocation will just
immediately free everything when the range check fails under the lock. Could
this be used by a BPF program to induce excessive memory pressure?

>  	data.arena = arena;
>  	data.pages = &pages;
>  	data.i = 0;

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260925233538.5708-1-emil@etsalapatis.com?part=3