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

  - hfsplus修正 __hfs_bnode_create 中遺漏的 hfs_bnode_get()。同時呼叫 sync() 和 link() 時兩個執行緒可能進入 hfs_bnode_find() 卻未在雜湊表中找到節點然後繼續建立該節點。執行緒 Ahfsplus_write_inode() -> hfsplus_write_system_inode() -> hfs_btree_write() -> hfs_bnode_find(tree, 0) -> __hfs_bnode_create(tree, 0) 執行緒 Bhfsplus_create_cat() -> hfs_brec_insert()
    -> hfs_bnode_split() -> hfs_bmap_alloc() -> hfs_bnode_find(tree, 0) -> __hfs_bnode_create(tree, 0) 在此情況下執行緒 A 會建立 bnode、設定 refcnt=1並對其進行雜湊。執行緒 B 也會嘗試建立相同的 bnode並發現其已插入因此中斷自己的執行個體並在未取得節點的情況下使用雜湊的執行個體。 ``` node2 = hfs_bnode_findhash(tree, cnid); if (!node2) { <- 執行緒 A hash = hfs_bnode_hash(cnid); node->next_hash = tree->node_hash[hash]; tree->node_hash[hash] = node;
    tree->node_hash_cnt++ } else { <- 執行緒 B spin_unlock(&tree->hash_lock); kfree(node);
    wait_event(node2->lock_wq, !test_bit(HFS_BNODE_NEW, &node2->flags));傳回 node2 ``` 不過hfs_bnode_find() 會要求每次呼叫取得參照。此處兩個執行緒最終都會設定 refcnt=1。當他們稍後放置該節點時這會觸發 BUG_ON(!atomic_read(&node->refcnt)) 在此狀況下執行緒 B 實際上是在雜湊表中尋找節點而非建立新表因此必須取得參照。重複使用另一個執行緒新建立的 bnode 時藉由呼叫 hfs_bnode_get() 來修正此問題以確保正確更新 refcount。類似的錯誤已在很久以前的認可 a9dc087fd3c4 中於 HFS 中獲得修正 (修正 __hfs_bnode_create 中缺少的 hfs_bnode_get())但相同的問題仍然存在於 HFS+ 中。
    (CVE-2025-68774)

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

偵測

Linux Distros 未修補的弱點：CVE-2025-68774

high Nessus Plugin ID 283662

版本 1.32