CVE-2025-68774
Vulnérabilité élevée dans Linux (Linux)
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.
Gravité et risque d'exploitation
CVE-2025-68774 obtient un score CVSS de 7.5/10, soit une gravité élevée. Selon le modèle EPSS, la probabilité qu'elle soit exploitée dans les 30 prochains jours est de 0.59 %, ce qui la place devant 47.0 % des CVE référencées.
Que faire ?
- Vérifiez si Linux (versions 6.12.64, <=6.1.*, <=6.12.*, 2.6.12, 6.1.160, 0, 6.6.120, <152af114287851583cf7e0abc10129941f19466a, <2.6.12, 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2, 5.15.198, <=5.10.*, <=6.6.*, 6.18.3, <b9d1c6bb5f19460074ce9862cb80be86b5fb0a50, <39e149d58ef4d7883cbf87448d39d51292fd342d, <=6.18.*, 5.10.248, <b68dc4134b18a3922cd33439ec614aad4172bc86, <=*, <3b0fc7af50b896d0f3d104e70787ba1973bc0b56, <=5.15.*, 6.19, <5882e7c8cdbb5e254a69628b780acff89c78071e, <457f795e7abd7770de10216d7f9994a3f12a56d6) est présent sur votre parc.
- Appliquez le correctif ou la version corrigée indiqués dans les références de l'éditeur.
- À défaut de correctif, limitez l'exposition (filtrage réseau, désactivation du composant).
- Automatisez la détection : les agents CVE Heimdall (gratuits, open source) corrèlent l'inventaire de vos serveurs avec la base CVE.
Références
- https://git.kernel.org/stable/c/3b0fc7af50b896d0f3d104e70787ba1973bc0b56
- https://git.kernel.org/stable/c/39e149d58ef4d7883cbf87448d39d51292fd342d
- https://git.kernel.org/stable/c/b68dc4134b18a3922cd33439ec614aad4172bc86
- https://git.kernel.org/stable/c/b9d1c6bb5f19460074ce9862cb80be86b5fb0a50
- https://git.kernel.org/stable/c/457f795e7abd7770de10216d7f9994a3f12a56d6
- https://git.kernel.org/stable/c/5882e7c8cdbb5e254a69628b780acff89c78071e
- https://git.kernel.org/stable/c/152af114287851583cf7e0abc10129941f19466a
