CVE-2024-50038

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