Linux/Unix ホストには、ベンダーが提供するパッチが利用できない脆弱性の影響を受ける複数のパッケージがインストールされています。

  - net:thunderbolt:リングを停止する前に DMA パスをティアダウンします tbnet_tear_down() は、tb_xdomain_disable_paths() を呼び出す前に両方のリングを停止し、フレームバッファを解放します。tb_ring_stop() はリングの記述子ベースをゼロにし、tbnet_free_buffers() はフレームが置かれているページのマップを解除して解放します。
    __tb_path_deactivate_hop() はホップの「保留中」ビットをポーリングし、まだ飛行中のものは排出先がありません。ティアダウンのシーケンスは、ドライバーが追加されて以来、この順序になっています。セットアップパスには以下がありません。
    ff7cd07f3064 のコミット(net:thunderbolt:リングが有効化された後にのみ DMA パスを有効にします)は、パス enable を tbnet_connected_work() の終わりに移動し、その理由を文書化しました: /* 両方のログインが成功したため、リング、高速 DMA * パスを有効にし、ネットワークデバイスのキューを開始します。* * 注:着信パケットの到着が許可される前に * Rx リングを確実にプライミング * するために、最後に DMA パスを有効にします。*/ ティアダウンは一致するように更新されなかったため、リングとパスは、逆ではなく上に行くのと同じ順序で下がるようになりました。ASMedia ASM4242 ホストルーターで「pending」ビットは決してクリアされません。ティアダウンのたびに 500 ms のタイムアウトが消費され、__tb_path_deactivate_hop() は -ETIMEDOUT を返します。タイムアウトを 5 秒に上げても役に立たないので、ホップの排水は遅くなく、まったく排水されません。故障はサンダーボルトコアの上には見えません。__tb_path_deactivate_hops() は無効であり、tb_port_warn() のみを呼び出します。tb_path_deactivate()、tb_tunnel_deactivate() および __tb_disconnect_xdomain_paths() も無効であり、tb_disconnect_xdomain_paths() は無条件の戻り値 0 で終わります。そのため、tb_xdomain_disable_paths() は成功をレポートし、その下の netdev_warn() は決して起動されません。ティアダウンを繰り返すことで最終的に XDomain コントロールチャネルがダウンし、その後ピアノードがなくなり、電源を入れ直して初めてコントローラーが復旧します。
    パスを非アクティブ化すると、まず問題が修正されます。他のパッチを適用していないストック v6.17 ツリーで、アップしていてトラフィックを伝送したばかりのリンクの kretprobes で測定:before: __tb_path_deactivate_hop() は最初のホップに 0 を返し、次に 2 番目のホップに -ETIMEDOUT を返します500335後:両方に 0、525 us 離れて 3 つの負荷レベルで 2 つの順序 ABBA を交互に実行します。 アームあたり 4 回の分解: 変更前にすべての分解が失敗し (実行された 21 件中 21 件)、変更後に失敗したものはありません (24 件中 0 件)。リンクが途中で切れたため、前の腕は短くなりました。同じ分割は、インターフェイスが単にダウンするのではなく、結合の奴隷になるときに現れますが、それが私が最初にこれに遭遇した方法です。変更後のスループットと待機時間は変更されません。古い記述子ベースにもかかわらずルーターがホップを排出するホストでは、どちらの方法でもパスが無効になるため、機能に違いはありません。(CVE-2026-74691)

Nessus は、ベンダーから報告されたパッケージの存在に依存していることに注意してください。

検出

Linux Distros のパッチ未適用の脆弱性: CVE-2026-74691

high Nessus プラグイン ID 338962

バージョン 1.8