ZeroHour

CVE-2026-80725

mass

Out-of-Bounds Write in Linux Kernel GRO/BIG TCP Packet Aggregation

CVSS 3.1
9.8 critical
EPSS
<1%p38
Published
()
Modified
AI analysis

CVE-2026-80725 is a flaw in the Linux kernel's Generic Receive Offload (GRO) code, where the skb_gro_receive() function's validation for aggregating packets beyond the 64 KB legacy limit (BIG TCP) was loosened by commit b1a78b9b9886 and no longer correctly checks the space before the MAC header, the packet protocol, or encapsulation state. It can be triggered when GRO aggregates traffic past 64 KB on hosts using software VLAN (802.1Q/802.1AD), encapsulated flows such as SIT/IPv6-in-IPv4 tunnels, or frames injected locally via AF_PACKET, causing an out-of-bounds write and a wrapped skb->mac_header. An attacker who can deliver such traffic to an affected host gains kernel memory corruption, which can cause a crash (denial of service) and, per the critical 9.8 CVSS rating, potentially full system compromise. Affected systems are Linux stable branches predating the 7.0 GRO rewrite in commit 81be30c1f5f2, notably the 6.18.y branch; mainline 7.0 and later are not affected. No public proof-of-concept, CISA KEV listing, or in-the-wild exploitation is known, and EPSS estimates roughly a 0.5% probability of exploitation within 30 days.

What to do: Patch by updating to the latest 6.18.y stable kernel (or your distribution's backport) containing the corrected skb_gro_receive() BIG TCP validation; systems on mainline 7.0 or later are already fixed by the GRO rewrite. Until patched, avoid enabling BIG TCP on affected hosts by keeping GSO/GRO maximum sizes at the 64 KB legacy limit, and prioritize hosts running software VLAN or IPv6-in-IPv4 (SIT) tunnels. Check the running kernel (uname -r) against your distribution's security advisories for the 6.18.y fix.

Affected
Linux kernel (net: GRO/BIG TCP, skb_gro_receive)Stable branches predating the 7.0 GRO rewrite that carry commit b1a78b9b9886 (notably 6.18.y); mainline 7.0+ is not affected
Estimated exposure
masshundreds of millions of systems run Linux 6.x-era stable kernels carrying the vulnerable code, though only hosts actually aggregating GRO traffic above 64 KB… — Linux 6.x kernels are the current stable/LTS line deployed across servers, Android devices and embedded systems, but the flaw only manifests when GRO aggregation exceeds the 64 KB legacy limit, a configuration largely limited to BIG…

Order-of-magnitude estimate by the model from install counts, market share and public scan data it knows; verify before quoting.

Description

In the Linux kernel, the following vulnerability has been resolved: net: gro: properly validate BIG TCP aggregation criteria When GRO attempts to aggregate packets beyond GRO_LEGACY_MAX_SIZE (64KB), BIG TCP should only be permitted for plain IPv4 TCP and plain IPv6 TCP (with sufficient MAC header room to insert the temporary HBH jumbo header). However, commit b1a78b9b9886 ("net: add support for ipv4 big tcp") loosened the check in skb_gro_receive(), leading to several issues: 1. skb_gro_receive() checked skb_headroom(p) instead of the actual space before the MAC header (p->mac_header). Because skb_headroom(p) includes mac_len, crafted frames (e.g. injected via AF_PACKET) can pass the check with p->mac_header head, causing an out-of-bounds write and wrapping skb->mac_header. 2. It allowed non-IP protocols such as software VLAN (ETH_P_8021Q / ETH_P_8021AD) to aggregate beyond 64KB because p->protocol != ETH_P_IPV6 was true. 3. It checked p->encapsulation instead of NAPI_GRO_CB(skb)->encap_mark, allowing encapsulated flows (e.g. SIT / IPv6-in-IPv4) to aggregate beyond 64KB. Fix skb_gro_receive() to strictly enforce: - NAPI_GRO_CB(skb)->proto == IPPROTO_TCP - Not encapsulated (!NAPI_GRO_CB(skb)->encap_mark && !p->encapsulation) - Protocol must be either ETH_P_IP or ETH_P_IPV6 - If ETH_P_IPV6, p->mac_header must be at least sizeof(struct hop_jumbo_hdr) Returning -E2BIG from skb_gro_receive() ensures that packets which cannot become BIG TCP are cleanly flushed at <= 64KB and delivered intact without dropping. This issue does not exist in mainline (7.0+) because the subsystem was rewritten in commit 81be30c1f5f2 ("net/ipv6: Drop HBH for BIG TCP on RX side"), making this fix relevant only for older stable branches like 6.18.y.

Vector
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

In the news

No ingested article mentions this CVE yet.