Linux/Unix 主機上安裝了一個或多個受到弱點影響的套件，且廠商未提供可用的修補程式。

  - net：gro：正確驗證 BIG TCP 聚合標準 當 GRO 嘗試聚合超過 GRO_LEGACY_MAX_SIZE （64KB） 的封包時，僅允許普通 IPv4 TCP 和普通 IPv6 TCP 使用 BIG TCP（有足夠的 MAC 標頭空間來插入臨時 HBH 巨型標頭）。不過，請提交 b1a78b9b9886 （net：
    新增對 IPv4 大 TCP 的支援） 放寬了 skb_gro_receive（） 中的檢查，導致了幾個問題： 1.
    skb_gro_receive（） 檢查了 skb_headroom（p），而不是 MAC 標頭 （p->mac_header） 之前的實際空格。由於 skb_headroom（p） 包含 mac_len，因此特製的幀（例如透過 AF_PACKET 插入）可以通過 p->mac_header < 8 位元組的檢查。當 ipv6_gro_complete（） 插入臨時 HBH 巨型標頭時，memmove（） 會在 skb->head 之前啟動，導致越界寫入並包裝 skb->mac_header。2. 它允許軟體 VLAN （ETH_P_8021Q / ETH_P_8021AD） 等非 IP 協定聚合超過 64KB，因為 p->protocol ！= ETH_P_IPV6 為 true。3. 它檢查了 p->encapsulation 而不是 NAPI_GRO_CB（skb）->encap_mark，允許封裝流量（例如 SIT / IPv6-in-IPv4）聚合超過 64KB。修正 skb_gro_receive（） 以嚴格執行： - NAPI_GRO_CB（skb）->proto == IPPROTO_TCP - 未封裝 （！NAPI_GRO_CB（skb）->encap_mark &&; ！p->encapsulation） - 通訊協定必須是 ETH_P_IP 或 ETH_P_IPV6 - 如果ETH_P_IPV6，p->mac_header 必須至少是 sizeof（struct hop_jumbo_hdr） 從 skb_gro_receive（） 傳回 -E2BIG 可確保無法成為 BIG TCP 的封包在 <= 64KB 時被乾淨地排清，並完整地傳遞而不會丟棄。主線 （7.0+） 中不存在此問題，因為子系統已在提交 81be30c1f5f2 中重寫 （net/ipv6：刪除 RX 端 BIG TCP 的 HBH），因此此修正僅適用於較舊的穩定分支，例如 6.18.y。CVE-2026-80725

請注意，Nessus 的判定取決於廠商所報告的套件是否存在。

偵測

Linux Distros 未修補弱點：CVE-2026-80725

critical Nessus Plugin ID 341561

版本 1.1