From: Jiayuan Chen <[email protected]> Date: Fri, 12 Jun 2026 21:07:45 +0800 > From: Weiming Shi <[email protected]> > > When the scatterlist ring is full or nearly full, bpf_msg_push_data() > enters a copy fallback path and computes copy + len for the page > allocation size. Since len comes from BPF with arg3_type = ARG_ANYTHING > and both are u32, a crafted len can wrap the sum to a small value, > causing an undersized allocation followed by an out-of-bounds memcpy. > > BUG: unable to handle page fault for address: ffffed104089a402 > Oops: Oops: 0000 [#1] SMP KASAN NOPTI > Call Trace: > __asan_memcpy (mm/kasan/shadow.c:105) > bpf_msg_push_data (net/core/filter.c:2852 net/core/filter.c:2788) > bpf_prog_9ed8b5711920a7d7+0x2e/0x36 > sk_psock_msg_verdict (net/core/skmsg.c:934) > tcp_bpf_sendmsg (net/ipv4/tcp_bpf.c:421 net/ipv4/tcp_bpf.c:584) > __sys_sendto (net/socket.c:2206) > do_syscall_64 (arch/x86/entry/syscall_64.c:94) > entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) > > Add an overflow check before the allocation. > > Link: https://lore.kernel.org/all/[email protected] > Fixes: 6fff607e2f14 ("bpf: sk_msg program helper bpf_msg_push_data") > Tested-by: Xiang Mei <[email protected]> > Tested-by: Xinyu Ma <[email protected]> > Reviewed-by: Jiayuan Chen <[email protected]> > Reviewed-by: Emil Tsalapatis <[email protected]> > Signed-off-by: Weiming Shi <[email protected]> > Signed-off-by: Jiayuan Chen <[email protected]> > --- > To sashiko: > > Regarding bpf_msg_push_data() reading "copy = msg->sg.data[i].length" with > i == msg->sg.end (appending at the very end of a full/near-full ring): > > This is pre-existing code, not touched by this series, and reproducing it > needs > a narrow combination -- a pure append at the end so the loop exits with > i == msg->sg.end, a full/near-full ring, plus a prior push/pop history that > leaves a stale length in the otherwise-unused end slot. A freshly built ring > zeroes that slot, so copy stays 0. We don't consider it practically > reproducible. > > Even then it's already covered: the overflow check in patch 1 ("copy + len < > copy") rejects the dangerous case, and __GFP_ZERO in patch 3 prevents any data > exposure. Not worth fixing here. > --- > net/core/filter.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/net/core/filter.c b/net/core/filter.c > index 9590877b0714f..3c8f1cedb217f 100644 > --- a/net/core/filter.c > +++ b/net/core/filter.c > @@ -2829,6 +2829,9 @@ BPF_CALL_4(bpf_msg_push_data, struct sk_msg *, msg, > u32, start, > if (!space || (space == 1 && start != offset)) > copy = msg->sg.data[i].length; > > + if (unlikely(copy + len < copy)) > + return -EINVAL;
Who wants to push E2BIG "metadata or option" ? :( https://docs.ebpf.io/linux/helper-function/bpf_msg_push_data/ I feel this is the same class of "bug" we discussed recently, but given the change is just small validation, Reviewed-by: Kuniyuki Iwashima <[email protected]>
