CVE Catalog

CVE-2025-68774

HighCVSS 7.5
Published: Updated: Translated: NVD NIST

Exploitation Probability (EPSS)

Low risk
0.49%

39th percentile - higher than 39% of all known CVEs

Summary

In the Linux kernel's HFS+ filesystem, a vulnerability was found due to a missing hfs_bnode_get() call in __hfs_bnode_create(). When sync() and link() are called concurrently, two threads may attempt to create the same B-tree node, leading to a double-free and triggering a BUG_ON assertion.

Risk Assessment

The vulnerability can cause a kernel panic (system crash) due to the BUG_ON assertion, resulting in service disruption and potential data loss.

Recommendation

Immediately update the Linux kernel to a version containing the fix (commit addressing the HFS+ issue). For production systems, apply the security patch after testing.

Other vulnerabilities in Linux kernel

See all
Original NVD description (English source)

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.

Vulnerability data from NVD (NIST) · CISA KEV · EPSS