Re: [PATCH v3 bpf-next 2/9] bpf: tcp: Add a new per-socket flag and kfunc for bpf_tcp_ops.
flat view
From: bot+bpf-ci@kernel.org
Date: 2026-10-05 16:27:20
Also in:
bpf
bpf: tcp: Add a new per-socket flag and kfunc for bpf_tcp_ops.
TL;DR: The bpf_tcp_ops_set_flags() kfunc filter seems to let cgroup_skb and sock_ops programs call it too, not just bpf_tcp_ops and cgroup_sockopt; this is an API scope issue, not memory safety.
quoted hunk ↗ jump to hunk
diff --git a/net/ipv4/bpf_tcp_ops.c b/net/ipv4/bpf_tcp_ops.c --- a/net/ipv4/bpf_tcp_ops.c +++ b/net/ipv4/bpf_tcp_ops.c
[ ... ]
quoted hunk ↗ jump to hunk
+static int bpf_tcp_ops_set_flags_kfunc_filter(const struct bpf_prog *prog, + u32 kfunc_id) +{ + if (!btf_id_set8_contains(&bpf_tcp_ops_set_flags_kfunc_set, kfunc_id)) + return 0; + + if (prog->type == BPF_PROG_TYPE_STRUCT_OPS && + prog->aux->st_ops != &bpf_tcp_ops) + return -EACCES; + + return 0; +}
[ ... ]
quoted hunk ↗ jump to hunk
static int __init __bpf_tcp_ops_init(void) { - return register_bpf_struct_ops(&bpf_tcp_ops, bpf_tcp_ops); + int ret; + + ret = register_btf_kfunc_id_set(BPF_PROG_TYPE_STRUCT_OPS, + &bpf_tcp_ops_set_flags_kfunc_id_set); + ret = ret ?: register_btf_kfunc_id_set(BPF_PROG_TYPE_CGROUP_SOCKOPT, + &bpf_tcp_ops_set_flags_kfunc_id_set);
The commit message says the kfunc is exposed to bpf_tcp_ops and
BPF_PROG_TYPE_CGROUP_SOCKOPT. Does this registration limit it to those two
program types?
register_btf_kfunc_id_set(BPF_PROG_TYPE_CGROUP_SOCKOPT, ...) puts the set
into the shared BTF_KFUNC_HOOK_CGROUP hook. bpf_prog_type_to_kfunc_hook()
in kernel/bpf/btf.c maps CGROUP_SKB, CGROUP_SOCK, CGROUP_DEVICE,
CGROUP_SOCK_ADDR, CGROUP_SOCKOPT, CGROUP_SYSCTL and SOCK_OPS all to that
one hook.
btf_kfunc_is_allowed() looks the kfunc up in that hook and then only runs
the hook filters, and bpf_tcp_ops_set_flags_kfunc_filter() returns 0 for
every program type except a STRUCT_OPS program that is not bpf_tcp_ops:
if (prog->type == BPF_PROG_TYPE_STRUCT_OPS &&
prog->aux->st_ops != &bpf_tcp_ops)
return -EACCES;
return 0;
That seems to let BPF_PROG_TYPE_CGROUP_SKB and BPF_PROG_TYPE_SOCK_OPS
programs call bpf_tcp_ops_set_flags() as well. Both program types provide
bpf_tcp_sock() (cg_skb_func_proto and sock_ops_func_proto in
net/core/filter.c), and the verifier accepts the returned PTR_TO_TCP_SOCK
as a trusted struct tcp_sock * through reg2btf_ids[].
For cgroup_skb the likely caller is an ingress program running in softirq
context. The commit message mentions cgroup_skb only as a possible future
use.
The cmpxchg update keeps this memory safe, so this is about API scope:
once programs start using the kfunc from these other program types,
narrowing it later would break them.
bpf_qdisc_kfunc_filter() and scx_kfunc_context_filter() both reject the
program types they do not intend to serve. If only bpf_tcp_ops and
CGROUP_SOCKOPT are intended, should the filter reject prog->type values
other than BPF_PROG_TYPE_STRUCT_OPS and BPF_PROG_TYPE_CGROUP_SOCKOPT?
Otherwise, could the commit message list the actual set of program types
that can call the kfunc?
This filter is unchanged through 3cb5919af2b2 ("selftest: bpf: Add test for
bpf_tcp_ops.{enqueue,dequeue}_rcvq()."), so no later patch in the series
changes it.
quoted hunk ↗ jump to hunk
+ ret = ret ?: register_bpf_struct_ops(&bpf_tcp_ops, bpf_tcp_ops); + + return ret; }
[ ... ] --- 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/37336989320