Re: [PATCH nf-next] netfilter: x_tables: reject missing '-p' flag and check for INV flag

On Sat, Aug 22, 2026 at 10:14:19AM +0200, Florian Westphal wrote:
> Pablo Neira Ayuso <[email protected]> wrote:
> > On Fri, Aug 21, 2026 at 03:41:36PM +0200, Florian Westphal wrote:
> > > ip6tables traverser doesn't walk ipv6 extension headers unless the PROTO
> > > flag is set, so direct sockopt-users can bypass the check (ip6tables
> > > always sets it if '-p' flag is given.  This is a cleanup patch, it
> > > doesn't fix any real bug.
> > 
> > I really think it is better to squash the TPROXY fix into this one
> > too, it is the same logical fix.
> 
> I don't mind either way.  I did not do it because unlike TPROXY these
> are benign.
>
> > Sashiko also hinting to fix ip6_tables core check for this protocol
> > flag:
> > 
> > https://sashiko.dev/#/patchset/20260821134136.18191-1-fw%40strlen.de
> 
> Not so sure.  Maybe just do this?  I don't think proto > 0 and flag
> unset makes any sense.
> 
> diff --git a/net/ipv6/netfilter/ip6_tables.c b/net/ipv6/netfilter/ip6_tables.c
> --- a/net/ipv6/netfilter/ip6_tables.c
> +++ b/net/ipv6/netfilter/ip6_tables.c
> @@ -647,6 +647,13 @@ check_entry_size_and_hooks(struct ip6t_entry *e,
>  	/* Clear counters and comefrom */
>  	e->counters = ((struct xt_counters) { 0, 0 });
>  	e->comefrom = 0;
> +
> +	/* Make sure F_PROTO is set, else ip6_packet_match
> +	 * won't do the right thing.
> +	 */
> +	if (e->ipv6.proto)
> +		e->ipv6.flags |= IP6T_F_PROTO;

Userspace always provides a zeroed e->ipv6.proto when unused, correct?

If so, LGTM.

> +
>  	return 0;
>  }
>