CVE-2026-80725: net: gro: properly validate BIG TCP aggregation criteria

Published Aug 29, 2026
·
Updated

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 GROLEGACYMAXSIZE (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 skbgroreceive(), leading to several issues:

1. skbgroreceive() checked skbheadroom(p) instead of the actual space before the MAC header (p->macheader). Because skbheadroom(p) includes maclen, crafted frames (e.g. injected via AFPACKET) can pass the check with p->macheader < 8 bytes. When ipv6grocomplete() inserts the temporary HBH jumbo header, the memmove() starts before skb->head, causing an out-of-bounds write and wrapping skb->macheader. 2. It allowed non-IP protocols such as software VLAN (ETHP8021Q / ETHP8021AD) to aggregate beyond 64KB because p->protocol != ETHPIPV6 was true. 3. It checked p->encapsulation instead of NAPIGROCB(skb)->encapmark, allowing encapsulated flows (e.g. SIT / IPv6-in-IPv4) to aggregate beyond 64KB.

Fix skbgroreceive() to strictly enforce: - NAPIGROCB(skb)->proto == IPPROTOTCP - Not encapsulated (!NAPIGROCB(skb)->encapmark && !p->encapsulation) - Protocol must be either ETHPIP or ETHPIPV6 - If ETHPIPV6, p->macheader must be at least sizeof(struct hopjumbohdr)

Returning -E2BIG from skbgroreceive() 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.

Affected Software

1 affected component
Linux Kernel Linux kernel<7.0

Remediation

Recommended actions to resolve this vulnerability, in priority order.

  1. Upgrade

    Upgrade to a fixed release to a version that resolves this vulnerability.

    Patch b1a78b9b9886
  2. Upgrade

    Upgrade to a fixed release to a version that resolves this vulnerability.

    Patch 81be30c1f5f2
  3. Upgrade

    Upgrade Linux kernel to a version that resolves this vulnerability.

    Fixed in 6.18.y
  4. Configuration

    Update skb_gro_receive() to strictly enforce BIG TCP aggregation criteria: require NAPI_GRO_CB(skb)->proto == IPPROTO_TCP, protocol must be either ETH_P_IP or ETH_P_IPV6, and BIG TCP should only be allowed for plain IPv4 TCP and plain IPv6 TCP; also check encapsulation using NAPI_GRO_CB(skb)->encap_mark instead of p->encapsulation.

    skb_gro_receive() (GRO BIG TCP validation in Linux kernel) encapsulation check = Use NAPI_GRO_CB(skb)->encap_mark instead of p->encapsulation; and ensure only plain IPv4 TCP and plain IPv6 TCP are permitted for BIG TCP
  5. Configuration

    Ensure skb_gro_receive() returns -E2BIG when packets cannot be aggregated within GRO_LEGACY_MAX_SIZE (64KB), so oversized aggregates are cleanly flushed/dropped rather than causing an out-of-bounds write.

    skb_gro_receive() (GRO) return code on invalid aggregation size = -E2BIG
  6. Configuration

    Fix skb_gro_receive() to validate skb_headroom against the actual required space before inserting the temporary IPv6 HBH jumbo header (so memmove does not start before skb->head when p->mac_header < 8 bytes).

    skb_gro_receive() (GRO) MAC header room validation for temporary HBH jumbo header = Require p->mac_header >= 8 bytes before inserting temporary HBH jumbo header (sizeof(struct hop_jumbo_hdr) / memmove safety)

Event History

Aug 29, 2026
CVE Published
via MITRE·06:39 AM
Data Sourced
via MITRE·06:39 AM
Description

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203