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

  - netdsa正確追踪管道參照 問題描述 ------------------- DSA 在處理管道網路裝置及其 kobject 時有參照的 mumbo-jumbo遺憾的是這是錯誤的而且沒有意義。有兩個明顯的問題。 1. 使用 of_find_net_device_by_node() 的 OF 路徑在管道的 kobject 上永遠不會釋放提升的 refcount。名義上OF 和非 OF 路徑應導致產生具有相同參照計數的物件且 dsa_dev_to_net_device() 具有 dsa_port_parse_of() 中遺漏的 put_device() 呼叫已經是可疑的但我們實際上甚至可以驗證存在問題。在 CONFIG_DEBUG_KOBJECT_RELEASE=y 的情況下如果我們在套用此修補程式之前和之後執行此命令 (解除系結網路裝置 eno2 的管道驅動程式) echo 0000:00:00.2 > /sys/bus/pci/drivers/fsl_enetc/unbind 我們會看到這些行在僅在套用修補程式之後才會顯示的輸出 diff 中。若發現管道介面單向 (OF) 或另一向 (非 OF)則可隨時將其取消註冊且 DSA 會保持為長效但在此情況下會過時的 cpu_dp->conduit 指標。保留網路裝置的基礎 kobject 實際上沒有太大幫助只會防止其被釋放 (但我們絕不會直接需要該 kobject)。有助於我們防止網路裝置遭取消註冊的是平行 netdev 參照機制 (dev_hold() 和 dev_put())。實際上我們自提交 2f1e8ea726e9 (netdsa連結與 DSA 主機的介面以去除 lockdep 警告) 以來便透過 netdev_upper_dev_link() 在使用者連接埠上隱含使用該 netdev 追踪器機制。但在 DSA 交換器探查時間仍會在 of_find_net_device_by_node() 程式碼的初始時間和使用者連接埠建立時間之間時間流轉在此期間管道可自行取消註冊而 DSA 不會知道這點。因此我們必須在 rtnl_lock() 下執行 of_find_net_device_by_node() 以防止該情況發生並只在 netdev 追踪器已取得參照時釋放鎖定。是否需要保留參照直到 dsa_unregister_switch() / dsa_switch_shutdown() 為止1：可以。即使所有使用者連接埠都無法探查仍會註冊交換器裝置請參閱認可 86f8b1c01a0a (netdsa不要使使用者連接埠錯誤變成嚴重錯誤)且 cpu_dp->conduit 指標維持有效。我尚未稽核所有呼叫路徑以查看它們是否真的會在缺少任何使用者連接埠的情況下使用管道但如果會使用則不依賴使用者連接埠進行該參照似乎更安全。 2. 絕對可以。我們支援變更與使用者連接埠相關聯的管道而且我們可能會將管道中的所有使用者連接埠移走因此不再透過 net 裝置追踪器保留對其的任何參照。但是我們不應該就此放棄 - 請參閱與 dsa_tree_find_first_conduit() 和 LAG 管道有關的下一個變更這些變更會消失。我們必須準備好傳回實體管道因此 CPU 連接埠必須明確保留其另一個參照。這也是說使用者連接埠及其 CPU 連接埠未必會一律保持對相同管道網路裝置的參照而兩者都是必要的。至於 /sys/class/net/ 項目的管道 kobject 我們並不在意只要我們保留網路裝置物件本身就可以將其釋放。歷程記錄和責備屬性 ----------------- 程式碼已重構多次因此非常難以遵循和正確歸因於責備不過我會嘗試做一個簡短的歷程記錄希望其為正確的。
    我們有兩個不同的探查路徑- 一個用於 OF在 2016 年引入 i ---truncated--- (CVE-2025-71152)

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

偵測

Linux Distros 未修補的弱點：CVE-2025-71152

critical Nessus Plugin ID 296382

版本 1.1