CVE-2024-50038 Affecting kernel-tools-libs-devel package, versions *
Threat Intelligence
Do your applications use this vulnerable package?
In a few clicks we can analyze your entire application and see what components are vulnerable in your application, and suggest you quick fixes.
Test your applications- Snyk ID SNYK-RHEL8-KERNELTOOLSLIBSDEVEL-8286106
- published 23 Oct 2024
- disclosed 21 Oct 2024
Introduced: 21 Oct 2024
CVE-2024-50038 Open this link in a new tabHow to fix?
There is no fixed version for RHEL:8 kernel-tools-libs-devel.
NVD Description
Note: Versions mentioned in the description apply only to the upstream kernel-tools-libs-devel package and not the kernel-tools-libs-devel package as distributed by RHEL.
See How to fix? for RHEL:8 relevant fixed versions and status.
In the Linux kernel, the following vulnerability has been resolved:
netfilter: xtables: avoid NFPROTO_UNSPEC where needed
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.
While at it, bail out if connbytes fails to enable the corresponding conntrack family.
This change passes the selftests in iptables.git.
References
- https://access.redhat.com/security/cve/CVE-2024-50038
- https://git.kernel.org/stable/c/0bfcb7b71e735560077a42847f69597ec7dcc326
- https://git.kernel.org/stable/c/4cdc55ec6222bb195995cc58f7cb46e4d8907056
- https://git.kernel.org/stable/c/85ff9a0f793ca52c527e75cd40a69c948627ebde
- https://git.kernel.org/stable/c/8f482bb7e27b37f1f734bb9a8eeb28b23d59d189
- https://git.kernel.org/stable/c/997f67d813ce0cf5eb3cdb8f124da68141e91b6c