Re: [PATCH bpf 3/4] bpf, sockmap: zero-initialize pages allocated in bpf_msg_push_data

[sashiko-bot@kernel.org]

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

Pre-existing issues:
- [High] The patch intended to fix a heap information leak in `bpf_msg_push_data()` but mistakenly modified `bpf_msg_pull_data()` instead. The uninitialized memory exposure in `bpf_msg_push_data()` remains active.
--

commit 6cfebe959c2ffe911ff763388e942ea998f90682
Author: Weiming Shi <bestswngs@gmail.com>

bpf, sockmap: zero-initialize pages allocated in bpf_msg_push_data

The commit intends to fix a kernel heap information leak in bpf_msg_push_data
by zero-initializing the allocated page before adding it to the scatterlist.
It adds the __GFP_ZERO flag to the alloc_pages call to prevent stale kernel
pointers from leaking to userspace.

Link: https://lore.kernel.org/all/20260424155913.A19FDC19425@smtp.kernel.org

> diff --git a/net/core/filter.c b/net/core/filter.c
> index 3e555f276ba80..982d59cf659f5 100644
> --- a/net/core/filter.c
> +++ b/net/core/filter.c
> @@ -2716,7 +2716,7 @@ BPF_CALL_4(bpf_msg_pull_data, struct sk_msg *, msg, u32, start,
>  	if (unlikely(bytes_sg_total > copy))
>  		return -EINVAL;
>  
> -	page = alloc_pages(__GFP_NOWARN | GFP_ATOMIC | __GFP_COMP,
> +	page = alloc_pages(__GFP_NOWARN | GFP_ATOMIC | __GFP_COMP | __GFP_ZERO,
>  			   get_order(copy));

[Severity: High]
This isn't a bug introduced by this patch, but this patch completely fails to
fix the issue described in the commit message.

The commit message states the fix is for bpf_msg_push_data, but the diff
applies the __GFP_ZERO flag to bpf_msg_pull_data instead.

In bpf_msg_pull_data, the bytes exposed to the scatterlist are already fully
initialized via memcpy, making the __GFP_ZERO flag unnecessary overhead.

Meanwhile, the alloc_pages call in bpf_msg_push_data still lacks the __GFP_ZERO
flag, leaving the original information leak fully exploitable:

net/core/filter.c:bpf_msg_push_data() {
        ...
        page = alloc_pages(__GFP_NOWARN | GFP_ATOMIC | __GFP_COMP,
                           get_order(copy + len));
        ...
}

Could the __GFP_ZERO flag be moved to the correct alloc_pages call in
bpf_msg_push_data?

>  	if (unlikely(!page))
>  		return -ENOMEM;

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260611013547.247039-1-jiayuan.chen@linux.dev?part=3