Re: [PATCH bpf v2] bpf, sockmap: fix use-after-free when the stream parser resizes the skb

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] BPF program modifications to the packet payload and the `cb` array are lost for fragmented packets, breaking API contracts and state passing.
- [High] Returning 0 on `skb_clone` allocation failure causes a structural connection stall.
--

commit b299b25e2b7e463fddbfdeb09ab2432fcc43e867
Author: Sechang Lim <rhkrqnwk98@gmail.com>

bpf, sockmap: fix use-after-free when the stream parser resizes the skb

This commit fixes a use-after-free in the stream parser when a BPF program
resizes the skb. It runs the parser on a clone of the skb when the message
spans multiple fragments and the program can modify the packet data.

> diff --git a/net/core/skmsg.c b/net/core/skmsg.c
> index e1850caf1a71a..97e5bc5f38c35 100644
> --- a/net/core/skmsg.c
> +++ b/net/core/skmsg.c
> @@ -1149,9 +1149,29 @@ static int sk_psock_strp_parse(struct strparser *strp, struct sk_buff *skb)
>  	rcu_read_lock();
>  	prog = READ_ONCE(psock->progs.stream_parser);
>  	if (likely(prog)) {
[ ... ]
> +		if (skb_has_frag_list(skb) && prog->aux->changes_pkt_data) {
> +			parse_skb = skb_clone(skb, GFP_ATOMIC);
> +			if (!parse_skb) {
> +				rcu_read_unlock();
> +				return 0;

[Severity: High]
Does returning 0 here cause a connection stall?

In the strparser framework (__strp_recv), a return value of 0 from parse_msg
explicitly signals that it needs more data to determine the message length.
This causes the parser to consume the current bytes and suspend parsing until
new data arrives.

If the sender has transmitted a complete request and is waiting for a response,
will the connection stall indefinitely since no new data will arrive?

> +			}
> +		}
> +		parse_skb->sk = psock->sk;
> +		ret = bpf_prog_run_pin_on_cpu(prog, parse_skb);
> +		parse_skb->sk = NULL;
> +		if (parse_skb != skb)
> +			consume_skb(parse_skb);

[Severity: High]
If the BPF program modifies the cb array or packet payload on the clone
(parse_skb), do these changes get silently discarded when consume_skb()
is called?

BPF sk_skb programs are explicitly permitted to use the cb array (the first
20 bytes of skb->cb) to pass state between the stream parser and stream
verdict programs.

When the program runs on a transient clone, modifications to the cb array or
the packet payload are lost when the clone is freed. For non-fragmented
packets, the program runs on the original skb and modifications persist.

Could this structural inconsistency break BPF programs that rely on state
passing, or allow attackers to bypass BPF security policies by artificially
fragmenting traffic?

>  	}
>  	rcu_read_unlock();
>  	return ret;

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