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

  - af_unixunix_add_edge() で scc_index を初期化します。Quang Le 氏は、AF_UNIX GC が、有効なインフライトソケットの受信キューを適切なリプロでガベージコレクトする可能性があることを報告しました。repro は 3 つのステージで構成されています。 1) 1-a. 多数のソケット 1-b で単一の循環参照を作成します。すべてのソケット 1-c を閉じます。トリガーGC 2) 2-a. sk-A を embrio sk-B 2-b に渡します。sk-X を sk-X 2-c に渡します。トリガー GC 3) 3-a. embrio sk-B 3-b を受け入れます。sk-B を sk-C 3-c に渡します。 in-flight sk-A 3-d を閉じます。2-c としての Trigger GC、sk-A と sk-X は unix_unvisited_vertices にリンクされており、unix_walk_scc() はそれらを 2 つの異なる SCC にグループ化します
    unix_sk(sk-A)->vertex->scc_index = 2UNIX_VERTEX_INDEX_STARTunix_sk(sk-X)->vertex->scc_index = 3 GC が完了すると、unix_graph_grouped は true に設定されます。また、unix_graph_maybe_cycle は、sk-X の循環自己参照により、true に設定されています。これにより、close() が GC をトリガーします。3-b では、unix_add_edge() が unix_sk(sk-B)->vertex を割り当て、これを unix_unvisited_vertices にリンクします。 unix_update_graph() は 3-a で呼び出されます。および 3-b. ですが、sk-B のリスナーおよび sk-C の両方が in-flight ではないため、unix_graph_grouped も unix_graph_maybe_cycle も変更されません。 3-cはsk-Aのファイルrefcntを1にデクリメントします。unix_graph_groupedが3-dでtrueであるため、unix_walk_scc_fast()が最終的に呼び出され、3つのソケットsk-A、sk-B、sk-Xを反復しますsk-A -> sk -B (-> sk-C) sk-X -> sk-X これは完全に問題ありません。それらはすべてまだ close()d ではなく、異なる SCC にグループ化する必要があります。しかし、unix_vertex_dead() は、sk-A と sk-B が同じ SCC にあり、sk-A が固まっていると間違って判断します。 unix_sk(sk-A)->scc_index == unix_sk(sk-B)->scc_index <-- 間違っています&& sk-A のファイル refcnt == unix_sk(sk-A)->vertex->out_degree u-- sk-B のための 1 つのインフライトカウント -> sk-A がデッド ! 問題は、unix_add_edge() が scc_index を初期化しないことです。ステージ 1) はヒープスプレーに使用され、新たに割り当てられた vertex に vertex->scc_index == 2UNIX_VERTEX_INDEX_STARTが 1-c で unix_walk_scc() で設定されます。
    以前の unix_walk_scc() の呼び出しから最大 SCC インデックスを追跡し、最大 + 1 を新しい vertex の scc_index に割り当てます。これにより、判断ミスを防ぎながら、Tarjan のアルゴリズムを回避し続けることができます。
    (CVE-2025-40214)

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

検出

Linux Distros のパッチ未適用の脆弱性: CVE-2025-40214

high Nessus プラグイン ID 277490

バージョン 1.8