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

  - vlan：修正切換硬體 VLAN 卸載時的 skb_under_panic 和爭用 在較低裝置上切換硬體 VLAN TX 卸載 （NETIF_F_HW_VLAN_CTAG_TX 或 NETIF_F_HW_VLAN_STAG_TX） 會叫用 vlan_transfer_features（），這會動態變更 vlandev->hard_header_len。這會導致兩個問題： 1. 無鎖定 TX 路徑 （例如
    packet_snd 在 af_packet.c 中，ip6_finish_output2） 讀取 dev->hard_header_len 而不持有 RTNL 鎖定。
    在 RTNL 下動態變異hard_header_len會產生資料爭用，其中上層根據過時的hard_header_len保留不足的餘量，導致呼叫 vlan_dev_hard_header（） 時出現skb_under_panic。2、此外，vlan_transfer_features（）在沒有更新header_ops的情況下更新了hard_header_len，導致分配的餘量與標頭建立不相符。一律設定 dev->hard_header_len = real_dev->hard_header_len 和 dev->needed_headroom = real_dev->needed_headroom + VLAN_HLEN 無條件地確保：- dev->hard_header_len 在 real_dev->hard_header_len 時保持 100% 靜態且不可變，消除hard_header_len上的所有動態執行階段更新和資料爭用。- 透過 LL_RESERVED_SPACE（） 配置 skb 的上層將始終為軟體 VLAN 標籤插入保留足夠的空間 （real_dev->hard_header_len + real_dev->needed_headroom + VLAN_HLEN）。- vlandev 繼承了 real_dev->needed_tailroom因此遵循基礎拖車/填充/ICV 要求。- AF_PACKET SOCK_RAW網路標頭位移在 real_dev->hard_header_len 處保持正確對齊。- 無條件使用vlan_header_ops。穩定團隊注意事項：確保將這些提交向後移植： e16e960d55a4 （ipvlan：從 phy_dev 繼承needed_headroom和needed_tailroom） cef51860becd （macvlan：從 lowerdev 繼承 needed_headroom 和 needed_tailroom） （CVE-2026-80925）

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

偵測

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

medium Nessus Plugin ID 344379

版本 1.8