CVE-2024-50038

Source
https://nvd.nist.gov/vuln/detail/CVE-2024-50038
Import Source
https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2024-50038.json
JSON Data
https://api.osv.dev/v1/vulns/CVE-2024-50038
Downstream
Related
Published
2024-10-21T20:15:16Z
Modified
2025-08-09T19:01:27Z
Severity
  • 5.5 (Medium) CVSS_V3 - CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H CVSS Calculator
Summary
[none]
Details

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/xtcluster.c:72 xtclustermt+0x196/0x780 [..] ebtdo_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 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 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

Affected packages