<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
  <id>https://vulnerability.circl.lu/rss/recent/all/10</id>
  <title>Most recent entries from all</title>
  <updated>2026-09-30T03:37:21.695890+00:00</updated>
  <author>
    <name>Vulnerability-Lookup</name>
    <email>info@circl.lu</email>
  </author>
  <link href="https://vulnerability.circl.lu" rel="alternate"/>
  <generator uri="https://lkiesow.github.io/python-feedgen" version="1.0.0">python-feedgen</generator>
  <subtitle>Contains only the most 10 recent entries.</subtitle>
  <entry>
    <id>https://vulnerability.circl.lu/vuln/cve-2026-80725</id>
    <title>CVE-2026-80725 — net: gro: properly validate BIG TCP aggregation criteria</title>
    <updated>2026-09-30T03:37:21.697441+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> Linux</p>
<p>In the Linux kernel, the following vulnerability has been resolved:</p>
<p>net: gro: properly validate BIG TCP aggregation criteria</p>
<p>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).</p>
<p>However, commit b1a78b9b9886 ("net: add support for ipv4 big tcp")
loosened the check in skb_gro_receive(), leading to several issues:</p>
<p>1. skb_gro_receive() checked skb_headroom(p) instead of the actual space
   before the MAC header (p-&gt;mac_header). Because skb_headroom(p) includes
   mac_len, crafted frames (e.g. injected via AF_PACKET) can pass the check
   with p-&gt;mac_header &lt; 8 bytes. When ipv6_gro_complete() inserts the
   temporary HBH jumbo header, the memmove() starts before skb-&gt;head,
   causing an out-of-bounds write and wrapping skb-&gt;mac_header.
2. It allowed non-IP protocols such as software VLAN (ETH_P_8021Q /
   ETH_P_8021AD) to aggregate beyond 64KB because
   p-&gt;protocol != ETH_P_IPV6 was true.
3. It checked p-&gt;encapsulation instead of NAPI_GRO_CB(skb)-&gt;encap_mark,
   allowing encapsulated flows (e.g. SIT / IPv6-in-IPv4) to aggregate
   beyond 64KB.</p>
<p>Fix skb_gro_receive() to strictly enforce:
- NAPI_GRO_CB(skb)-&gt;proto == IPPROTO_TCP
- Not encapsulated (!NAPI_GRO_CB(skb)-&gt;encap_mark &amp;&amp; !p-&gt;encapsulation)
- Protocol must be either ETH_P_IP or ETH_P_IPV6
- If ETH_P_IPV6, p-&gt;mac_header must be at least
  sizeof(struct h…</p></div>
    </content>
    <link href="https://vulnerability.circl.lu/vuln/cve-2026-80725"/>
  </entry>
</feed>
