| Message ID | 20260822210945.1003967-2-Jeremy.Jean@oss.cyber.gouv.fr |
|---|---|
| State | New |
| Headers | show |
| Series | netfilter: bpf: disallow conntrack kfuncs for token programs | expand |
On Sat Aug 22, 2026 at 11:09 PM CEST, Jérémy Jean wrote: > BPF tokens delegate BPF and network-admin capability checks to the token > owning user namespace. Conntrack kfuncs nevertheless accept a network > namespace ID relative to the program context without checking whether the > token has authority over the resolved namespace. > > An XDP program attached to a veth in a child network namespace can use > the peer namespace ID for init_net. bpf_xdp_ct_alloc() then allocates an > entry in init_net, bpf_ct_insert_entry() publishes it, and the lookup and > mutation kfuncs can subsequently access that host state. > > The verifier retains the token in prog->aux, but it cannot determine the > runtime namespace selected through bpf_ct_opts. Conservatively reject the > conntrack kfunc set for token-loaded programs. The kfunc interface is > explicitly unstable, and ordinary token-authorized XDP programs remain > available. > > Fixes: caf8f28e036c ("bpf: Add BPF token support to BPF_PROG_LOAD command") > Assisted-by: Codex:gpt-5 > Signed-off-by: Jérémy Jean <Jeremy.Jean@oss.cyber.gouv.fr> So your solution is to just begin rejecting its use? Proper scoping and containerization of programs is a bigger project that needs more thought. It needs to be addressed properly across the API surface, we probably have several other helpers/kfuncs that have similar ns-unaware behavior. If we went on to simply reject each case programs using BPF tokens would basically become useless. pw-bot: cr > [...]
On 2026-08-23 21:12, Kumar Kartikeya Dwivedi wrote: > On Sat Aug 22, 2026 at 11:09 PM CEST, Jérémy Jean wrote: >> BPF tokens delegate BPF and network-admin capability checks to the >> token >> owning user namespace. Conntrack kfuncs nevertheless accept a network >> namespace ID relative to the program context without checking whether >> the >> token has authority over the resolved namespace. >> >> An XDP program attached to a veth in a child network namespace can use >> the peer namespace ID for init_net. bpf_xdp_ct_alloc() then allocates >> an >> entry in init_net, bpf_ct_insert_entry() publishes it, and the lookup >> and >> mutation kfuncs can subsequently access that host state. >> >> The verifier retains the token in prog->aux, but it cannot determine >> the >> runtime namespace selected through bpf_ct_opts. Conservatively reject >> the >> conntrack kfunc set for token-loaded programs. The kfunc interface is >> explicitly unstable, and ordinary token-authorized XDP programs remain >> available. >> >> Fixes: caf8f28e036c ("bpf: Add BPF token support to BPF_PROG_LOAD >> command") >> Assisted-by: Codex:gpt-5 >> Signed-off-by: Jérémy Jean <Jeremy.Jean@oss.cyber.gouv.fr> > > So your solution is to just begin rejecting its use? Proper scoping and > containerization of programs is a bigger project that needs more > thought. > It needs to be addressed properly across the API surface, we probably > have > several other helpers/kfuncs that have similar ns-unaware behavior. > > If we went on to simply reject each case programs using BPF tokens > would > basically become useless. > > pw-bot: cr > >> [...] Hello, Thanks for your answer. I merely raised the issue to you; there indeed may exist more similar ones. However, I unfortunately don't have enough time to allocate to a broader fix. Regards, Jérémy
diff --git a/net/netfilter/nf_conntrack_bpf.c b/net/netfilter/nf_conntrack_bpf.c index c2df7c9..4075ee1 100644 --- a/net/netfilter/nf_conntrack_bpf.c +++ b/net/netfilter/nf_conntrack_bpf.c @@ -532,9 +532,24 @@ BTF_ID_FLAGS(func, bpf_ct_set_status) BTF_ID_FLAGS(func, bpf_ct_change_status) BTF_KFUNCS_END(nf_ct_kfunc_set) +static int nf_conntrack_kfunc_filter(const struct bpf_prog *prog, u32 kfunc_id) +{ + /* + * Conntrack kfuncs accept a netns ID relative to the program context. + * The verifier cannot determine which user namespace owns that target. + * Do not let a token delegate authority over arbitrary peer netns state. + */ + if (prog->aux->token && + btf_id_set8_contains(&nf_ct_kfunc_set, kfunc_id)) + return -EACCES; + + return 0; +} + static const struct btf_kfunc_id_set nf_conntrack_kfunc_set = { .owner = THIS_MODULE, .set = &nf_ct_kfunc_set, + .filter = nf_conntrack_kfunc_filter, }; int register_nf_conntrack_bpf(void)
BPF tokens delegate BPF and network-admin capability checks to the token owning user namespace. Conntrack kfuncs nevertheless accept a network namespace ID relative to the program context without checking whether the token has authority over the resolved namespace. An XDP program attached to a veth in a child network namespace can use the peer namespace ID for init_net. bpf_xdp_ct_alloc() then allocates an entry in init_net, bpf_ct_insert_entry() publishes it, and the lookup and mutation kfuncs can subsequently access that host state. The verifier retains the token in prog->aux, but it cannot determine the runtime namespace selected through bpf_ct_opts. Conservatively reject the conntrack kfunc set for token-loaded programs. The kfunc interface is explicitly unstable, and ordinary token-authorized XDP programs remain available. Fixes: caf8f28e036c ("bpf: Add BPF token support to BPF_PROG_LOAD command") Assisted-by: Codex:gpt-5 Signed-off-by: Jérémy Jean <Jeremy.Jean@oss.cyber.gouv.fr> --- net/netfilter/nf_conntrack_bpf.c | 15 +++++++++++++++ 1 file changed, 15 insertions(+)