CVE-2025-68774
Awaiting Analysis Awaiting Analysis - Queue
BaseFortify

Publication date: 2026-01-13

Last updated on: 2026-01-19

Assigner: kernel.org

Description
In the Linux kernel, the following vulnerability has been resolved: hfsplus: fix missing hfs_bnode_get() in __hfs_bnode_create When sync() and link() are called concurrently, both threads may enter hfs_bnode_find() without finding the node in the hash table and proceed to create it. Thread A: hfsplus_write_inode() -> hfsplus_write_system_inode() -> hfs_btree_write() -> hfs_bnode_find(tree, 0) -> __hfs_bnode_create(tree, 0) Thread B: hfsplus_create_cat() -> hfs_brec_insert() -> hfs_bnode_split() -> hfs_bmap_alloc() -> hfs_bnode_find(tree, 0) -> __hfs_bnode_create(tree, 0) In this case, thread A creates the bnode, sets refcnt=1, and hashes it. Thread B also tries to create the same bnode, notices it has already been inserted, drops its own instance, and uses the hashed one without getting the node. ``` node2 = hfs_bnode_findhash(tree, cnid); if (!node2) { <- Thread A hash = hfs_bnode_hash(cnid); node->next_hash = tree->node_hash[hash]; tree->node_hash[hash] = node; tree->node_hash_cnt++; } else { <- Thread B spin_unlock(&tree->hash_lock); kfree(node); wait_event(node2->lock_wq, !test_bit(HFS_BNODE_NEW, &node2->flags)); return node2; } ``` However, hfs_bnode_find() requires each call to take a reference. Here both threads end up setting refcnt=1. When they later put the node, this triggers: BUG_ON(!atomic_read(&node->refcnt)) In this scenario, Thread B in fact finds the node in the hash table rather than creating a new one, and thus must take a reference. Fix this by calling hfs_bnode_get() when reusing a bnode newly created by another thread to ensure the refcount is updated correctly. A similar bug was fixed in HFS long ago in commit a9dc087fd3c4 ("fix missing hfs_bnode_get() in __hfs_bnode_create") but the same issue remained in HFS+ until now.
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2026-01-13
Last Modified
2026-01-19
Generated
2026-05-07
AI Q&A
2026-01-14
EPSS Evaluated
2026-05-05
NVD
CVE-2025-68774
Affected Vendors & Products
Currently, no data is known.
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-UNKNOWN
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?

This vulnerability occurs in the Linux kernel's HFS+ filesystem code when two threads concurrently call sync() and link(), leading both to attempt to create the same bnode in the hash table. Thread A creates the bnode and sets its reference count to 1, while Thread B also tries to create the same bnode but finds it already inserted and uses the existing one without properly increasing its reference count. This causes both threads to have a refcount of 1 instead of correctly incrementing it, which can later trigger a kernel bug due to incorrect reference counting. The fix involves calling hfs_bnode_get() to properly update the reference count when reusing a bnode created by another thread.


How can this vulnerability impact me? :

This vulnerability can lead to a kernel BUG_ON error due to incorrect reference counting of filesystem nodes, potentially causing system instability or crashes when the affected code paths are executed concurrently. This can impact system reliability and may lead to data corruption or denial of service if the kernel crashes or behaves unpredictably.


What immediate steps should I take to mitigate this vulnerability?

The vulnerability is fixed by updating the Linux kernel to a version that includes the patch for the missing hfs_bnode_get() call in __hfs_bnode_create. Therefore, the immediate mitigation step is to update your Linux kernel to the latest version where this fix is applied.


Ask Our AI Assistant
Need more information? Ask your question to get an AI reply (Powered by our expertise)
0/70
EPSS Chart