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

  - netfilter： arp_tables：修正 IEEE1394 ARP 負載剖析 石未明說：arp_packet_match（） 會無條件地剖析 ARP 負載，假設存在兩個硬體位址 （來源和目標）。
    不過，IPv4-over-IEEE1394 ARP （RFC 2734） 會省略目標硬體位址欄位，而 arp_hdr_len（） 已透過傳回較短的裝置長度來說明這一點ARPHRD_IEEE1394。因此，在介面上 IEEE1394 ，arp_packet_match（） 會越過不存在的目標硬體位址，並讀取目標裝置位址比較和目標 IP 位址的錯誤位元組。這會導致 arptables 規則與垃圾資料相符，從而導致不正確的過濾決策：應該接受的封包可能會被丟棄，反之亦然。net/ipv4/arp.c （arp_create 和 arp_process） 中的 ARP 堆疊已透過跳過目標硬體位址來正確處理此問題ARPHRD_IEEE1394。將相同的模式套用至 arp_packet_match（）。破壞原始修補程式，以一律傳回 0 （不相符），以防使用者在目標硬體位址上相符，而 中從未存在 IEEE1394。請注意，這會傳回 0 （不相符） 用於正常比對和反向比對，因為 arptables 從未支援 ARPHRD_IEEE1394 中目標硬體位址的比對。這是有意為之，目標硬體位址上的比對不應針對ARPHRD_IEEE1394評估為 true。此外，按照 AI 的建議調整arpt_mangle以丟棄封包：在 arpt_mangle 中，邏輯採用標準 ARP 佈局。由於 （FireWire） 省略了目標硬體位址，因此 IEEE1394 線性指標算術會錯誤計算目標 IP 位址的位移。這會導致修改作業寫入錯誤的位置，進而導致封包損毀。為確保安全，此修補程式會在要求對裝置上的 IEEE1394 這些欄位進行修改時丟棄封包 （NF_DROP），因為目前的實作無法正確對應 FireWire ARP 承載。
    這會同時省略錯誤目標硬體和 IP 位址。即使 中應該可以 IEEE1394修改 IP 位址，這也需要調整偏移計算，而這從未受到支援arpt_mangle。
    基於 Weiming Shi <bestswngs@gmail.com>的補丁。（CVE-2026-45844）

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

偵測

Linux Distros 未修補的弱點：CVE-2026-45844

medium Nessus Plugin ID 317074

版本 1.20