Re: [PATCH 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 2 potential issue(s) to consider:
- [High] Pages zeroed with __GFP_ZERO are mapped to user space without a dcache flush, potentially causing information leaks on cache-aliasing architectures.
- [Medium] bpf_map_alloc_page_sleepable() silently drops the task's NUMA mempolicy when the map's numa_node is NUMA_NO_NODE.
--

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

bpf: Add a sleepable page allocator for map memory

This commit introduces a sleepable page allocator for BPF map memory.
It utilizes alloc_pages_node() with GFP_KERNEL to allow reclaim and
OOM handling, intending to be used by the arena page fault handler.

> 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)
> +
> +/*
> + * For callers that know they run in a sleepable context, e.g. a user page
> + * fault handler. can_alloc_pages() is a conservative guess made for BPF
> + * program context - notably it is always false on PREEMPT_RT - so going
> + * through bpf_map_alloc_pages() there would needlessly pick the
> + * non-blocking allocator, which never reclaims and never engages the OOM
> + * machinery.
> + */
> +struct page *bpf_map_alloc_page_sleepable(const struct bpf_map *map)
> +{
> +	might_sleep();
> +	return alloc_pages_node(map->numa_node, BPF_PAGE_GFP, 0);

[Severity: High]
If this page is mapped to user space via a fault handler, will the use of
__GFP_ZERO included in BPF_PAGE_GFP cause an information leak on
cache-aliasing architectures?

Looking at bpf_map_alloc_page_sleepable() in kernel/bpf/syscall.c, the
allocator provides __GFP_ZERO pages. On cache-aliasing architectures, the
clear_page() function used by __GFP_ZERO clears memory via the kernel's
direct mapping but skips the dcache flush to main memory. If a page is
mapped to user space without the flush provided by clear_user_highpage(),
user programs can potentially read stale, uninitialized data directly from
main memory.

[Severity: Medium]
Does calling alloc_pages_node() unconditionally drop the task's NUMA
mempolicy when map->numa_node is NUMA_NO_NODE?

When map->numa_node is NUMA_NO_NODE in bpf_map_alloc_page_sleepable(),
passing it directly to alloc_pages_node() bypasses task NUMA policies
(such as those set by mbind() or set_mempolicy()) and defaults allocations
to the local CPU's node. This can result in pages landing on the wrong
NUMA node.

> +}

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