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

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.