Re: [PATCH bpf-next v4 1/4] bpf: Reject TCP_NODELAY in TCP header option callbacks

[KaFai Wan <kafai.wan@linux.dev>]

On Tue, 2026-04-21 at 16:51 +0000, bot+bpf-ci@kernel.org wrote:
> > diff --git a/net/core/filter.c b/net/core/filter.c
> > index 5fa9189eb772..96849f4c1fbc 100644
> > --- a/net/core/filter.c
> > +++ b/net/core/filter.c
> > @@ -5833,6 +5833,12 @@ BPF_CALL_5(bpf_sock_ops_setsockopt, struct bpf_sock_ops_kern *, bpf_sock,
> >  	if (!is_locked_tcp_sock_ops(bpf_sock))
> >  		return -EOPNOTSUPP;
> > 
> > +	/* TCP_NODELAY triggers tcp_push_pending_frames() and re-enters these callbacks. */
> > +	if ((bpf_sock->op == BPF_SOCK_OPS_HDR_OPT_LEN_CB ||
> > +	     bpf_sock->op == BPF_SOCK_OPS_WRITE_HDR_OPT_CB) &&
> > +	    level == SOL_TCP && optname == TCP_NODELAY)
> > +		return -EOPNOTSUPP;
> > +
> 
> Does this same recursion vulnerability exist for BPF TCP congestion
> control algorithms using BPF_PROG_TYPE_STRUCT_OPS?
> 
> If a BPF congestion control algorithm invokes bpf_setsockopt(TCP_NODELAY)
> from its cwnd_event callback when handling CA_EVENT_TX_START, could it
> trigger unbounded recursion through this path:
> 
> BPF_PROG_TYPE_STRUCT_OPS cwnd_event callback (CA_EVENT_TX_START)
>   -> bpf_setsockopt(TCP_NODELAY)
>     -> tcp_push_pending_frames()
>       -> tcp_write_xmit()
>         -> tcp_transmit_skb()
>           -> tcp_event_data_sent()
>             -> cwnd_event()
>               -> BPF congestion control cwnd_event callback
> 
> The author confirmed this issue in the v3 discussion thread and Martin
> KaFai Lau suggested creating a new func_proto
> (bpf_sk_setsockopt_nodelay_proto) to reject TCP_NODELAY for all struct_ops
> programs, but this patch only addresses BPF_SOCK_OPS callbacks.

patch#2 ("bpf: Reject TCP_NODELAY in bpf-tcp-cc") fix this, pls check.
> 
> Reference: https://lore.kernel.org/bpf/20260418092235.98444C19424@smtp.kernel.org/
> 
> 
> Does this fix also need to block TCP_CORK when the value is 0?

TCP_CORK is not support, return -EINVAL by default in sol_tcp_sockopt().
> 
> When bpf_setsockopt() is called with SOL_TCP and TCP_CORK with value 0
> (disabling cork), the call path goes through __tcp_sock_set_cork() in
> net/ipv4/tcp.c, which unconditionally calls tcp_push_pending_frames(sk)
> when cork is disabled:
> 
> __tcp_sock_set_cork()
>   -> tcp_push_pending_frames()
>     -> tcp_current_mss()
>       -> tcp_established_options()
>         -> bpf_skops_hdr_opt_len()
>           -> BPF_SOCK_OPS_HDR_OPT_LEN_CB
> 
> This triggers the same recursion chain described in the commit message,
> but the patch only blocks TCP_NODELAY, not TCP_CORK with value 0.
> 
> Reference:
> https://lore.kernel.org/bpf/5fea6b5e9d1a13e72edf8222a8ebe50cbb660b37e62b87b65dab6f6f317943ec@mail.kernel.org/
> 
> >  	return _bpf_setsockopt(bpf_sock->sk, level, optname, optval, optlen);
> >  }
> > 
> 
> 
> ---
> AI reviewed your patch. Please fix the bug or email reply why it's not a bug.
> See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md
> 
> CI run summary: https://github.com/kernel-patches/bpf/actions/runs/24733356810

-- 
Thanks,
KaFai