CVE-2024-35884: udp: do not accept non-tunnel GSO skbs landing in a tunnel
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
Security readout for executives and security teams
Plain-English summary
This Linux kernel flaw can mishandle forwarded UDP packets when offload features merge packets before they enter a tunnel. On exposed systems, this can corrupt network traffic or crash the kernel. The published CVSS score is 8.8, so prioritize systems that route tunneled UDP traffic.
Executive priority
Treat this as a high-priority infrastructure patching issue. Focus first on network forwarding, virtualization, Kubernetes, SDN, and embedded appliance environments where tunnel traffic is common. No active exploitation is documented in the supplied sources.
Technical view
When rx-udp-gro-forwarding or rx-gro-list is enabled, non-tunnel UDP GSO packets may be GROed before landing in a tunnel, especially across network namespaces. Geneve is cited. Incorrect GSO metadata after tunnel header handling can cause corrupted packets or kernel crashes in skb processing.
Likely exposure
Linux systems acting as routers, hypervisors, container hosts, or appliances using UDP tunnels such as Geneve are most relevant, especially with GRO forwarding features enabled. Ordinary Linux hosts without forwarding or tunnel use appear less likely exposed based on the supplied description.
Exploitation context
The source bundle does not show CISA KEV listing or confirmed active exploitation. The issue is network-reachable with low attack complexity but requires privileges per CVSS. Public sources describe kernel crash and corruption outcomes, not a weaponized exploit.
Researcher notes
The fix extends udp_unexpected_gso checks so non-tunnel GSO packets lacking UDP tunnel flags are segmented before tunnel processing. Evidence points to packet corruption and kernel crash risk, but the bundle does not provide a complete affected-version matrix beyond kernel stable references.
Mitigation direction
Apply vendor kernel updates containing the referenced stable fixes.
Prioritize container, virtualization, SDN, and appliance hosts using UDP tunnels.
Check Debian LTS and appliance vendor advisories for packaged fixes.
If patching is delayed, review vendor guidance for GRO or tunnel-related workarounds.
Do not run direct deployment changes without normal change control.
Validation and detection
Inventory Linux kernel versions across routing, container, and virtualization hosts.
Identify systems using Geneve or other UDP tunnel interfaces.
Check whether rx-udp-gro-forwarding or rx-gro-list is enabled.
Confirm installed kernels include the relevant stable fix for each branch.
Monitor kernel logs for skb_segment BUG_ON or tunnel-related crashes.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cve · low confidence lookup
CVE-2024-35884 mapping review
Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
We collect every scored CVSS vector available in the official CNA and ADP containers. When more than one version is present, the table keeps the source vectors side by side instead of collapsing them into the highest score.