Re: [PATCH] netfilter: bpf: disallow conntrack kfuncs for token programs
Jérémy Jean <[email protected]>
| Newsgroups | org.kernel.vger.bpf,org.kernel.vger.linux-kernel,org.kernel.vger.netdev,org.kernel.vger.netfilter-devel |
|---|---|
| Message-ID | <[email protected]> |
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 <[email protected]>
>
> 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