Re: [RFC] netfilter: disable payload mangling in userns

[Pablo Neira Ayuso <pablo@netfilter.org>]

On Fri, May 15, 2026 at 02:48:05PM +0200, Florian Westphal wrote:
> Qi Tang <tpluszz77@gmail.com> wrote:
> > I agree with the userns block.  I'll keep pushing the five
> > consumer-side bounds-check patches: root in init userns can
> > still install the same payload-set rule and trigger the same
> > OOB at the re-read sites, so the underlying bug fix is still
> > worth landing.
> > 
> > None of the five sites overlap with the relax wishlist (saddr/
> > daddr, transport, linklayer).  Same class showed up in an
> > earlier patch:
> >   https://lore.kernel.org/netdev/20260514035802.1540395-1-tpluszz77@gmail.com/
> > 
> > These five are unlikely to be all of them; we think the
> > consumer side warrants a broader audit.  Thoughts?
> 
> I think we have to do both.
> 
> For nft_payload/nft_exthdr:
> 1. Writes from !initial_userns are rejected (rule insert fails).
> 2. Writes for initial userns get validated at rule add time:
>   - netdev ingress is allowed to alter everything, I think
>   this is early enough to not introduce oddities that can't come
>   from wire / untrusted peer.
>  - bridge is allowed to alter everything: AFAICS there shouldn't
>  be a problem with this, same as with ingress.
>  - inet (ipv4/ip6): Check base (offset is unsigned and relative
>    to ll/network header/transport header/payload
>    - Allow modifications past transport header.
>    - Allow modifications of transport header
>    - Allow network header modifications for a subset of valid
>      offsets/lengths: saddr, daddr, checksum, tos, id, ttl / hl.
>      Reject everything else.
>    - Allow link-layer; but check at from packetpath that
>      offset + len don't write past start of the network header.
>      Else: no-op.
> 
> nfqueue is the bigger problem: userspace gives us a whole new
> packet data blob, not a delta that we should apply at offset x).
>
> I think we have to update nfqueue to do rudimentary header revalidation
> and drop the packet on failure, e.g. at least making sure tot_len is not
> past skb->len.

Agreed, nfqueue has been there for long time and such parser would
validate the packet is correct from stack POV.

But if a new function to validate that the IP header mangling is not
valid is feasible, then why not simply apply the same sanitization
from inet hooks to nft_payload/nft_exthdr?

That can be a function in net/netfilter/utils.c.