Re: [PATCH nf v3] netfilter: xtables: avoid NFPROTO_UNSPEC where needed

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

On Mon, Oct 07, 2024 at 11:28:16AM +0200, Florian Westphal wrote:
> syzbot managed to call xt_cluster match via ebtables:
> 
>  WARNING: CPU: 0 PID: 11 at net/netfilter/xt_cluster.c:72 xt_cluster_mt+0x196/0x780
>  [..]
>  ebt_do_table+0x174b/0x2a40
> 
> Module registers to NFPROTO_UNSPEC, but it assumes ipv4/ipv6 packet
> processing.  As this is only useful to restrict locally terminating
> TCP/UDP traffic, register this for ipv4 and ipv6 family only.
> 
> Pablo points out that this is a general issue, direct users of the
> set/getsockopt interface can call into targets/matches that were only
> intended for use with ip(6)tables.
> 
> Check all UNSPEC matches and targets for similar issues:
> 
> - matches and targets are fine except if they assume skb_network_header()
>   is valid -- this is only true when called from inet layer: ip(6) stack
>   pulls the ip/ipv6 header into linear data area.
> - targets that return XT_CONTINUE or other xtables verdicts must be
>   restricted too, they are incompatbile with the ebtables traverser, e.g.
>   EBT_CONTINUE is a completely different value than XT_CONTINUE.
> 
> Most matches/targets are changed to register for NFPROTO_IPV4/IPV6, as
> they are provided for use by ip(6)tables.
> 
> The MARK target is also used by arptables, so register for NFPROTO_ARP too.
> 
> This change passes the selftests in iptables.git.

Applied. I editted and appended this for the connbyte chunk:

"While at it, bail out if connbytes fails to enable the corresponding
conntrack family."