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

  - drbdhandle_write_conflicts で欠如している kref_get を追加します。「two-primaries」が有効な場合、DRBD は同時書き込みを検出し、書き込み競合を処理しようとします。これにより、両方のノードで同じセクターに同時に書き込みを行う場合でも、一度は同一のデータで終了します。書き込みが完了します。superseed 書き込みの処理において、kref_get を忘れていました。その結果、初期の drbd_destroy_device および use-after-free、さらにはカーネルクラッシュが発生しました。関連性DRBD をランダムデータジェネレーターとして使用するべきではありません。明らかに 2 つのプライマリの全ユーザーは、レイヤーアップで同時書き込みを適切に処理します。これは、クラスターファイルシステムがいくつかの分散ロックマネージャーを使用し、仮想化環境でのライブ移行が、あるノードの書き込みを停止してから、他のノードの書き込みを開始することです。つまり、テストケース以外では、このコードパスは実際には使用されません。現時点で、DRBD 9 では状況が異なって処理されます。書き込み競合は今でも検出されますが、これについて巧妙に対応することはありません。代わりにハードを切断することにしました上位レイヤーは同時書き込みを送信できませんでした。その場合、それは責任です。CVE-2025-38708

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

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

  - drbd在 handle_write_conflicts 中添加缺少的 kref_get 启用“two-primaries”时DRBD 会尝试检测并发写入并处理写入冲突这样即使您在两个节点上同时写入同一扇区它们也会在一次中以相同的数据结束写入操作已完成。在处理超级种子的写入时我们忘记了 kref_get从而导致过早发生 drbd_destroy_device 和释放后使用以及进一步出现内核崩溃并出现征兆。相关性任何人不应将 DRBD 用作随机数据发生器并且显然所有双主用户都会在向上层正确处理并发写入。即群集文件系统使用某个分布式锁定管理器而虚拟化环境中的实时迁移会在一个节点上停止写入然后再开始在另一个节点上写入。这意味着除了用于测试用例之外，实际中永远不会采用此代码路径。仅供参考在 DRBD 9 中现在的处理方式有所不同。我们仍会检测写入冲突，但不再尝试对其进行智能处理。我们决定改为硬断开连接：上层不得提交并发写入。如果他们这样做了，那是他们的错。 (CVE-2025-38708)

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

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

  - drbd新增 handle_write_conflicts 中遺漏的 kref_get 在啟用 `two-primaries` 的情況下DRBD 會嘗試偵測並行寫入並處理寫入衝突因此即使您同時在兩個節點上寫入相同磁區它們最終也會有一次相同的資料寫入已完成。在處理被取代的寫入時我們忘記了 kref_get導致 drbd_destroy_device 過早發生並釋放後使用進一步造成核心損毀並出現症狀。相關性：任何人皆不應使用 DRBD 作為隨機資料產生器而且顯然雙主元組的所有使用者都正確處理了層上的並行寫入。也就是說叢集檔案系統使用一些分散式鎖定管理員且虛擬化環境中的即時移轉會先在一個節點上停止寫入然後再開始在另一個節點上寫入。這表示除了測試案例外絕不會在實際中採用此程式碼路徑。僅供參考在 DRBD 9 中現在的處理方式有所不同。我們仍會偵測寫入衝突但不會再嘗試明智地處理這些衝突。我們決定改為硬式中斷上層不得提交並行寫入。如果是這樣，那是他們的錯。 (CVE-2025-38708)

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

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

  - drbd: add missing kref_get in handle_write_conflicts With `two-primaries` enabled, DRBD tries to detect     concurrent writes and handle write conflicts, so that even if you write to the same sector     simultaneously on both nodes, they end up with the identical data once the writes are completed. In     handling superseeded writes, we forgot a kref_get, resulting in a premature drbd_destroy_device and use     after free, and further to kernel crashes with symptoms. Relevance: No one should use DRBD as a random     data generator, and apparently all users of two-primaries handle concurrent writes correctly on layer     up. That is cluster file systems use some distributed lock manager, and live migration in virtualization     environments stops writes on one node before starting writes on the other node. Which means that other     than for test cases, this code path is never taken in real life. FYI, in DRBD 9, things are handled     differently nowadays. We still detect write conflicts, but no longer try to be smart about them. We     decided to disconnect hard instead: upper layers must not submit concurrent writes. If they do, that's     their fault. (CVE-2025-38708)

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

An update of the linux package has been released.

ID	Name	Product	Family	Published	Updated	Severity
261562	Linux Distros のパッチ未適用の脆弱性: CVE-2025-38708	Nessus	Misc.	9/6/2025	9/8/2025	high
261562	Linux Distros 未修补的漏洞：CVE-2025-38708	Nessus	Misc.	9/6/2025	9/8/2025	high
261562	Linux Distros 未修補的弱點：CVE-2025-38708	Nessus	Misc.	9/6/2025	9/8/2025	high
261562	Linux Distros Unpatched Vulnerability : CVE-2025-38708	Nessus	Misc.	9/6/2025	9/8/2025	high
265433	Photon OS 4.0: Linux PHSA-2025-4.0-0864	Nessus	PhotonOS Local Security Checks	9/19/2025	9/19/2025	high

Detections

Analytics

Plugins Search

high

high

high

high

high