DEBIAN-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 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.