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

["Jérémy Jean" <jeremy.jean@oss.cyber.gouv.fr>]

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