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をリリースできないためメモリリークにつながります。- これらの値が「0」にリセットされると、「queue->tx_head」および「queue->tx_tail」への同時書き込みアクセスが、「macb_tx_poll()」または「macb_start_xmit()」から発生する可能性があります。- 「TX_USED」ビットが設定された、既に送信されたが、まだ処理されていないパケットで、送信がスタックする可能性があります。ただし、「queue->tx_head」および「queue->tx_tail」の操作により、「macb_tx_poll()」は「queue->tx_head == queue->tx_tail」であるため、処理するパケットがないと間違って想定します。この問題は、この位置に新しいパケットが配置された場合にのみ解決されます。これが、NFS root ファイルシステムで観測された回復時間が長くなる根本的な原因です。この問題を解決するには、最初に送信されないパケットがtxリングの先頭に配置されるように、txリングとtx skb配列をシャッフルします。さらに、「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 プラグイン ID 315671

バージョン 1.18