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

  - flow_dissector：讀取前檢查裝置類型 ETH_ADDRS __skb_flow_dissect（） 在要求 FLOW_DISSECTOR_KEY_ETH_ADDRS 時無條件地從 eth_hdr （skb） 讀取 12 個位元組。這假設 skb 在 mac_header 處具有有效的乙太網路標頭，但情況並非總是如此。該問題可能由以下原因觸發： 1. 在 L3 模式下建立 TUN 裝置 （IFF_TUN， hard_header_len=0） 2.在 eth_src 3 上安裝帶有花卉濾波器的 multiq qdisc。透過 AF_PACKET 傳送封包 由於 L3 模式下的 TUN 沒有鏈路層標頭，因此 mac_header 指向 L3 資料區。正如 KMSAN 所報告的那樣，流剖析器讀取 12 位元組的未初始化 skb 內存，然後通過 fl_set_masked_key（） 傳播並用作 __fl_lookup（） 中的 rhashtable 查找鍵。拒絕控制路徑中的過濾器（在 tc 過濾器添加時）是不可行的，因為 TC 過濾器塊可以在任意設備之間共享——安裝在乙太網上的過濾器稍後可能會通過共享塊對無標頭設備上的封包進行分類。裝置關聯在篩選器建立時不會固定。透過在 dev->type == ARPHRD_ETHER 上控制 memcpy 來解決此問題，這可確保只有真正的乙太網路框架封包的位址才能被讀取。這比先前的 hard_header_len >= 12 檢查更精確，後者會錯誤地通過非乙太網路鏈路類型，例如 IPoIB （ARPHRD_INFINIBAND，hard_header_len=24） 和 FDDI （hard_header_len=21），其 L2 標頭不是乙太網路格式。另外檢查 skb_mac_header_was_set（） 以防止 mac_header 是未設定的哨兵 （~0U） 的病態情況，這會導致 eth_hdr（） 傳回野生指標。對於act_mirred重新導向情況（乙太網路封包重新導向到共用 TC 區塊的非乙太網路裝置），將金鑰歸零是正確的行為：封包現在在目標裝置上進行分類，其中乙太網路位址比對在語義上沒有意義。注意：在非乙太網路裝置上，歸零金鑰將與配置為全零 MAC 位址的篩選器相符。這是先前行為的改進，其中未初始化的記憶體可以隨機比對任何篩選器。（CVE-2026-72444）

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

偵測

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

high Nessus Plugin ID 335675

版本 1.8