[PATCH] netfilter: bpf: disallow conntrack kfuncs for token programs

[PATCH] netfilter: bpf: disallow conntrack kfuncs for token programs

[Jérémy Jean]

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(+)

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)
-- 
2.47.3

Re: [PATCH] netfilter: bpf: disallow conntrack kfuncs for token programs

[Kumar Kartikeya Dwivedi]

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

> [...]

Re: [PATCH] netfilter: bpf: disallow conntrack kfuncs for token programs

[Jérémy Jean]

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