In the Linux kernel, the following vulnerability has been resolved: netfilter: xtables: avoid NFPROTOUNSPEC where needed syzbot managed to call xtcluster match via ebtables: WARNING: CPU: 0 PID: 11 at net/netfilter/xtcluster.c:72 xtclustermt+0x196/0x780 [..] ebtdotable+0x174b/0x2a40 Module registers to NFPROTOUNSPEC, 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 skbnetworkheader() 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 XTCONTINUE or other xtables verdicts must be restricted too, they are incompatbile with the ebtables traverser, e.g. EBTCONTINUE is a completely different value than XTCONTINUE. Most matches/targets are changed to register for NFPROTOIPV4/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. While at it, bail out if connbytes fails to enable the corresponding conntrack family. This change passes the selftests in iptables.git.