CVE-2024-35884

udp: do not accept non-tunnel GSO skbs landing in a tunnel

MEDIUM
5.5
CVSS Score
Published: May 19, 2024 at 08:34 AM UTC
Updated: October 15, 2026 at 01:17 AM UTC
3 products affected across 3 vendorsLinux KernelDebian LinuxSIMATIC S7-1500 TM MFP

Using Linux by Linux?

Get instant alerts when new vulnerabilities affect Linux - before attackers find them.

Real-time alertsTrack your software stackFree plan available
Severity
MEDIUM5.5
Exploit prediction
EPSS 0.7%
SSVC
No known exploit

Description

In the Linux kernel, the following vulnerability has been resolved: udp: do not accept non-tunnel GSO skbs landing in a tunnel When rx-udp-gro-forwarding is enabled UDP packets might be GROed when being forwarded. If such packets might land in a tunnel this can cause various issues and udp_gro_receive makes sure this isn't the case by looking for a matching socket. This is performed in udp4/6_gro_lookup_skb but only in the current netns. This is an issue with tunneled packets when the endpoint is in another netns. In such cases the packets will be GROed at the UDP level, which leads to various issues later on. The same thing can happen with rx-gro-list. We saw this with geneve packets being GROed at the UDP level. In such case gso_size is set; later the packet goes through the geneve rx path, the geneve header is pulled, the offset are adjusted and frag_list skbs are not adjusted with regard to geneve. When those skbs hit skb_fragment, it will misbehave. Different outcomes are possible depending on what the GROed skbs look like; from corrupted packets to kernel crashes. One example is a BUG_ON[1] triggered in skb_segment while processing the frag_list. Because gso_size is wrong (geneve header was pulled) skb_segment thinks there is "geneve header size" of data in frag_list, although it's in fact the next packet. The BUG_ON itself has nothing to do with the issue. This is only one of the potential issues. Looking up for a matching socket in udp_gro_receive is fragile: the lookup could be extended to all netns (not speaking about performances) but nothing prevents those packets from being modified in between and we could still not find a matching socket. It's OK to keep the current logic there as it should cover most cases but we also need to make sure we handle tunnel packets being GROed too early. This is done by extending the checks in udp_unexpected_gso: GSO packets lacking the SKB_GSO_UDP_TUNNEL/_CSUM bits and landing in a tunnel must be segmented. [1] kernel BUG at net/core/skbuff.c:4408! RIP: 0010:skb_segment+0xd2a/0xf70 __udp_gso_segment+0xaa/0x560

Affected

Our own answer: ranges merged, affected separated from platform-only, with confidence and review flags.

5.11 ≤ v < 5.15.1545.16 ≤ v < 6.1.855.6 ≤ v < 5.10.2156.2 ≤ v < 6.6.266.7 ≤ v < 6.8.56.96.9 rc16.9 rc29fd1ff5d2ac7181844735806b0a703c942365291
Vendor states this is fixed in 3001e7aa43d6691db2a878b0745b854bf12ddd19 (fixed)
Vendor states this is fixed in 3391b157780bbedf8ef9f202cbf10ee90bf6b0f8 (fixed)
Vendor states this is fixed in 35fe0e0b5c00bef7dde74842a2564c43856fbce4 (fixed)
Vendor states this is fixed in 3d010c8031e39f5fa1e8b13ada77e0321091011f (fixed)
Vendor states this is fixed in d12245080cb259d82b34699f6cd4ec11bdb688bd (fixed)
Vendor states this is fixed in d49ae15a5767d4e9ef8bbb79e42df1bfebc94670 (fixed)
Vendor states this is fixed in 5.10.215 (unaffected)
Vendor states this is fixed in 5.15.154 (unaffected)
Vendor states this is fixed in 5.6 (unaffected)
Vendor states this is fixed in 6.1.85 (unaffected)
Vendor states this is fixed in 6.6.26 (unaffected)
Vendor states this is fixed in 6.8.5 (unaffected)
Vendor states this is fixed in 6.9 (unaffected)

References (8)

Patch
Source: 416baaa9-dc9f-4396-8d5f-8c081fb06d67
https://git.kernel.org/stable/c/3001e7aa43d6691db2a878b0745b854bf12ddd19
Patch
Source: 416baaa9-dc9f-4396-8d5f-8c081fb06d67
https://git.kernel.org/stable/c/3391b157780bbedf8ef9f202cbf10ee90bf6b0f8
Patch
Source: 416baaa9-dc9f-4396-8d5f-8c081fb06d67
https://git.kernel.org/stable/c/35fe0e0b5c00bef7dde74842a2564c43856fbce4
Patch
Source: 416baaa9-dc9f-4396-8d5f-8c081fb06d67
https://git.kernel.org/stable/c/3d010c8031e39f5fa1e8b13ada77e0321091011f
Patch
Source: 416baaa9-dc9f-4396-8d5f-8c081fb06d67
https://git.kernel.org/stable/c/d12245080cb259d82b34699f6cd4ec11bdb688bd
Patch
Source: 416baaa9-dc9f-4396-8d5f-8c081fb06d67
https://git.kernel.org/stable/c/d49ae15a5767d4e9ef8bbb79e42df1bfebc94670
Third Party Advisory
Source: af854a3a-2127-422b-91ae-364da2661108
https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Source: 0b142b55-0307-4c5a-b3c9-f314f3fb7c5e
https://cert-portal.siemens.com/productcert/html/ssa-265688.html

SSVC — Action Prioritization

SSVCNo known exploitNot automatablePartial impact

SSVC signals action urgency (what to patch first), separate from CVSS which measures severity.

CVSS

Attack Vector
LOCAL
Complexity
LOW
Privileges
LOW
User Interaction
NONE
Scope
UNCHANGED
Confidentiality
NONE
Integrity
NONE
Availability
HIGH
Vector?

Quick Info

StatusMODIFIED
CWE
CWE-617

Get alerted

Stop reading CVE feeds looking for your own stack

Track the products you run and VulnTracker tells you when a new CVE affects them — with what is known about fixing it, and nothing about the rest.

Free plan, no card