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 は、ベンダーによって報告されたパッケージの存在に依存していることに注意してください。

An update of the linux package has been released.

The Linux/Unix host has one or more packages installed that are impacted by a vulnerability without a vendor supplied patch available.

  - af_unix: Initialise scc_index in unix_add_edge(). Quang Le reported that the AF_UNIX GC could garbage-     collect a receive queue of an alive in-flight socket, with a nice repro. The repro consists of three     stages. 1) 1-a. Create a single cyclic reference with many sockets 1-b. close() all sockets 1-c. Trigger     GC 2) 2-a. Pass sk-A to an embryo sk-B 2-b. Pass sk-X to sk-X 2-c. Trigger GC 3) 3-a. accept() the embryo     sk-B 3-b. Pass sk-B to sk-C 3-c. close() the in-flight sk-A 3-d. Trigger GC As of 2-c, sk-A and sk-X are     linked to unix_unvisited_vertices, and unix_walk_scc() groups them into two different SCCs:
    unix_sk(sk-A)->vertex->scc_index = 2 (UNIX_VERTEX_INDEX_START) unix_sk(sk-X)->vertex->scc_index = 3 Once     GC completes, unix_graph_grouped is set to true. Also, unix_graph_maybe_cyclic is set to true due to     sk-X's cyclic self-reference, which makes close() trigger GC. At 3-b, unix_add_edge() allocates     unix_sk(sk-B)->vertex and links it to unix_unvisited_vertices. unix_update_graph() is called at 3-a. and     3-b., but neither unix_graph_grouped nor unix_graph_maybe_cyclic is changed because both sk-B's listener     and sk-C are not in-flight. 3-c decrements sk-A's file refcnt to 1. Since unix_graph_grouped is true at     3-d, unix_walk_scc_fast() is finally called and iterates 3 sockets sk-A, sk-B, and sk-X: sk-A -> sk-B (->     sk-C) sk-X -> sk-X This is totally fine. All of them are not yet close()d and should be grouped into     different SCCs. However, unix_vertex_dead() misjudges that sk-A and sk-B are in the same SCC and sk-A is     dead. unix_sk(sk-A)->scc_index == unix_sk(sk-B)->scc_index <-- Wrong! && sk-A's file refcnt ==     unix_sk(sk-A)->vertex->out_degree ^-- 1 in-flight count for sk-B -> sk-A is dead !? The problem is that     unix_add_edge() does not initialise scc_index. Stage 1) is used for heap spraying, making a newly     allocated vertex have vertex->scc_index == 2 (UNIX_VERTEX_INDEX_START) set by unix_walk_scc() at 1-c.
    Let's track the max SCC index from the previous unix_walk_scc() call and assign the max + 1 to a new     vertex's scc_index. This way, we can continue to avoid Tarjan's algorithm while preventing misjudgments.
    (CVE-2025-40214)

Note that Nessus relies on the presence of the package as reported by the vendor.

Linux/Unix 主机中安装的一个或多个程序包受到一个漏洞影响，而供应商没有提供补丁程序。

  - af_unix初始化 unix_add_edge() 中的 scc_index。Quang Le 报告AF_UNIX GC 可能对活动中的套接字的接收队列进行垃圾回收并能很好地重现。重现由三个阶段组成。 1) 1-a. 创建具有多个套接字 1-b 的单个循环引用。 close() 所有套接字 1-c。触发 GC 2) 2-a. 将 sk-A 传至畸形 sk-B 2-b。将 sk-X 传递到 sk-X 2-c。触发 GC 3) 3-a. accept() 初始 sk-B 3-b。将 sk-B 传递到 sk-C 3-c。 close() 执行中的 sk-A 3-d。触发 GC 自 2-c 起sk-A 和 sk-X 已链接至 unix_unvisited_verticesunix_walk_scc() 将其分组为两个不同的 SCC
    unix_sk(sk-A)->vertex->scc_index = 2 (UNIX_VERTEX_INDEX_START) unix_sk(sk-X)->vertex->scc_index = 3 GC 完成后unix_graph_grouped 会设置为 true。此外由于 sk-X 的循环自引用unix_graph_maybe_logical 设置为 true这使得 close() 触发 GC。在 3-b处unix_add_edge() 分配 unix_sk(sk-B)->vertex 并将其链接到 unix_unvisited_vertices。在 3-a 调用 unix_update_graph()。和 3-b.但 unix_graph_grouped 和 unix_graph_maybe_logical 都未更改因为 sk-B 的侦听器和 sk-C 未在运行中。 3-c 将 sk-A 的 file 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 ^-- sk-B -> sk-A 的 1 个飞行中计数死了 !? 问题在于 unix_add_edge() 不会初始化 scc_index。阶段 1) 用于堆喷洒使新分配的顶点具有由 unix_walk_scc() 在 1-c 处设置的 vertex->scc_index == 2 (UNIX_VERTEX_INDEX_START)。
    让我们跟踪之前 unix_walk_scc() 调用的最大 SCC 索引，并将最大 + 1 的索引值分配给新顶点的 scc_index。这样我们就可以在防止误判的同时继续避开 Tarjan 的算法。
    (CVE-2025-40214)

请注意，Nessus 依赖供应商报告的程序包是否存在进行判断。

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

  - af_unix初始化 unix_add_edge() 中的 scc_index。Quang Le 報告AF_UNIX GC 可以記憶體回收活動中執行中通訊端的接收佇列 (以 nice repro)。repro 包含三個階段。 1) 1-a. 建立具有多個通訊端 1-b 的單一周期性參照。 close() 所有通訊端 1-c。觸發 GC 2) 2-a. 將 sk-A 傳遞至原始 sk-B 2-b。將 sk-X 傳遞至 sk-X 2-c。觸發 GC 3) 3-a. accept() 啟動 sk-B 3-b。將 sk-B 傳遞至 sk-C 3-c。 close() 執行中 sk-A 3-d。觸發 GC 自 2-c 起sk-A 和 sk-X 會連結至 unix_unvisited_vertices且 unix_walk_scc() 會將它們分組為兩個不同的 SCC
    unix_sk(sk-A)->vertex->scc_index = 2 (UNIX_VERTEX_INDEX_START) unix_sk(sk-X)->vertex->scc_index = 3 一旦 GC 完成unix_graph_grouped 就會設為 true。此外由於 sk-X 的周期性自我參照 unix_graph_maybe_cycle 設為 true這會使 close() 觸發 GC。在 3-bunix_add_edge() 會配置 unix_sk(sk-B)->vertex 並將其連結至 unix_unvisited_vertices。 3-a 會呼叫 unix_update_graph()。及 3-b.但 unix_graph_grouped 與 unix_graph_maybe_cycle 皆不會變更因為 sk-B 的接聽程式和 sk-C 都未進行中。 3-c 將 sk-A 的檔案 refcnt 遞減至 1。由於 unix_graph_grouped 在 3-d 為 true因此最終會呼叫 unix_walk_scc_fast() 並重複執行 3 個通訊端 sk-A、sk-B 和 sk-Xsk-A -> sk -B (-> sk-C) sk-X -> sk-X 這是完全沒有問題的。所有這些 SCC 都尚未執行 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 ^-- sk-B 的 1 個 in-flight 計數 -> sk-A 已失效 !? 問題在於 unix_add_edge() 未初始化 scc_index。階段 1) 用於堆積噴射使新配置的頂點具有 unix_walk_scc() 在 1-c 設定的 vertex->scc_index == 2 (UNIX_VERTEX_INDEX_START)。
    讓我們追踪來自先前 unix_walk_scc() 呼叫的最大 SCC 索引並將 max + 1 指派給新頂點的 scc_index。如此一來我們就可繼續避免使用 Tarjan 演算法同時防止誤判。
    (CVE-2025-40214)

請注意，Nessus 依賴供應商報告的套件存在。

ID	名称	产品	系列	发布时间	最近更新时间	严重程度
277490	Linux Distros のパッチ未適用の脆弱性: CVE-2025-40214	Nessus	Misc.	2025/12/4	2025/12/10	high
278075	Photon OS 5.0: Linux PHSA-2025-5.0-0708	Nessus	PhotonOS Local Security Checks	2025/12/10	2025/12/11	high
277490	Linux Distros Unpatched Vulnerability : CVE-2025-40214	Nessus	Misc.	2025/12/4	2025/12/10	high
277490	Linux Distros 未修补的漏洞：CVE-2025-40214	Nessus	Misc.	2025/12/4	2025/12/10	high
277490	Linux Distros 未修補的弱點：CVE-2025-40214	Nessus	Misc.	2025/12/4	2025/12/10	high

检测

插件搜索

high

high

high

high

high