CVE-2026-80725

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

1. skbgroreceive() checked skb_headroom(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 ipv6gro_complete() inserts the

   temporary HBH jumbo header, the memmove() starts before skb->head,

   causing an out-of-bounds write and wrapping skb->mac_header.

1. It allowed non-IP protocols such as software VLAN (ETHP8021Q /

   ETHP8021AD) to aggregate beyond 64KB because

   p->protocol != ETHPIPV6 was true.

1. It checked p->encapsulation instead of NAPIGROCB(skb)->encap_mark,

   allowing encapsulated flows (e.g. SIT / IPv6-in-IPv4) to aggregate

   beyond 64KB.

Fix skbgroreceive() to strictly enforce:

• NAPIGROCB(skb)->proto == IPPROTO_TCP
• Not encapsulated (!NAPIGROCB(skb)->encap_mark && !p->encapsulation)
• Protocol must be either ETHPIP or ETHPIPV6
• If ETHPIPV6, p->mac_header 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.