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

  - net：macb：啟用 tx 之前隨機播放 tx 環 Quanyang 觀察到，在 AMD ZynqMp 板上使用 NFS rootfs 時，rootfs 在暫停後可能需要較長的時間才能恢復。經調查，確定問題源自於 macb 驅動程式的問題。根據 Zynq UltraScale TRM [1]，當停用傳輸時，傳輸緩衝區佇列指標會重設為指向傳輸緩衝區佇列基址暫存器指定的位址。在目前的實作中，程式碼只是將「queue->tx_head」和「queue->tx_tail」重設為「0」。此方法存在幾個問題：- 已在 tx 通道中排入佇列的封包會以無訊息方式遺失，進而導致記憶體洩漏，因為無法釋放相關聯的 skb。- 當 'queue->tx_head' 或 'macb_start_xmit（）' 的值重設為 '0' 時，可能會從 'macb_tx_poll（）' 或 '（）' 對 'queue->tx_tail' 進行並行寫入存取。- 傳輸可能會卡在已發送的封包上，該封包已設定其「TX_USED」位元，但尚未處理。然而，由於 'queue->tx_head' 和 'queue->tx_tail' 的操控，'macb_tx_poll（）' 錯誤地假設沒有要處理的封包，因為 'queue->tx_head == queue->tx_tail'。只有將新封包放置在此位置時，才會解決此問題。這是 NFS 根檔案系統發現復原時間延長的根本原因。若要解決此問題，請隨機播放 tx 通道和 tx skb 陣列，讓第一個未傳送的封包位於 tx 通道的開頭。此外，請確定「queue->tx_head」和「queue->tx_tail」的更新已使用適當的鎖定妥善保護。[1] https://docs.amd.com/v/u/en-US/ug1085-zynq-ultrascale-trm （CVE-2026-43371）

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

偵測

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

medium Nessus Plugin ID 315671

版本 1.13