Re: [PATCH bpf-next v6 1/4] bpf: Add a sleepable page allocator for map memory

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [Critical] Pages allocated via `__bpf_alloc_page()` in non-sleepable contexts are not zeroed, leading to a critical information leak. When `can_alloc_pages()` is false (e.g., in BPF programs running inside a BPF spinlock where IRQs are disabled, or under the spinlock in `arena_vm_fault`), the allocator falls back to `alloc_pages_nolock(__GFP_ACCOUNT, nid, 0)`. Because `__GFP_ZERO` is omitted and the page is never manually cleared, uninitialized physical memory is returned and subsequently mapped into the BPF arena. User space can then read this uninitialized kernel memory. (Note: The originally provided concern regarding missing dcache flushes on cache-aliasing architectures is a false positive because BPF arenas are only supported on hardware-coherent PIPT architectures like x86_64, arm64, riscv64, etc., via `bpf_jit_supports_arena()`).
--

--- Patch [1]: [PATCH bpf-next v6 1/4] bpf: Add a sleepable page allocator for map memory ---
commit 49db9a147d01ab11180f1f75062c2ee24918b7a4
Author: Jiayuan Chen <jiayuan.chen@linux.dev>

bpf: Add a sleepable page allocator for map memory
    
This commit adds bpf_map_alloc_page_sleepable() for callers that are known to
be in a sleepable context. It allows them to use the normal blocking allocator
which can reclaim memory and engage the OOM machinery.

> diff --git a/kernel/bpf/syscall.c b/kernel/bpf/syscall.c
> --- a/kernel/bpf/syscall.c
> +++ b/kernel/bpf/syscall.c
> @@ -602,15 +602,14 @@ static bool can_alloc_pages(void)
>  		!IS_ENABLED(CONFIG_PREEMPT_RT);
>  }
>  
> +#define BPF_PAGE_GFP (GFP_KERNEL | __GFP_ZERO | __GFP_ACCOUNT | __GFP_NOWARN)
> +
>  static struct page *__bpf_alloc_page(int nid)
>  {
>  	if (!can_alloc_pages())
>  		return alloc_pages_nolock(__GFP_ACCOUNT, nid, 0);

[Severity: Critical]
This is a pre-existing issue, but does missing __GFP_ZERO here cause an
information leak?

When can_alloc_pages() evaluates to false (e.g., in BPF programs running
inside a BPF spinlock where IRQs are disabled, or under the spinlock in
arena_vm_fault), the allocator falls back to alloc_pages_nolock() without
zeroing the page. 

Because this uninitialized kernel memory can subsequently be mapped into the
BPF arena, user space could read it.

> -	return alloc_pages_node(nid,
> -				GFP_KERNEL | __GFP_ZERO | __GFP_ACCOUNT
> -				| __GFP_NOWARN,
> -				0);
> +	return alloc_pages_node(nid, BPF_PAGE_GFP, 0);
>  }

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