GHSA-2WRV-52XX-6XXV
Vulnerability from github – Published: 2026-01-13 18:31 – Updated: 2026-07-30 06:32In 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.
{
"affected": [],
"aliases": [
"CVE-2025-68774"
],
"database_specific": {
"cwe_ids": [],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-01-13T16:15:56Z",
"severity": "HIGH"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nhfsplus: fix missing hfs_bnode_get() in __hfs_bnode_create\n\nWhen sync() and link() are called concurrently, both threads may\nenter hfs_bnode_find() without finding the node in the hash table\nand proceed to create it.\n\nThread A:\n hfsplus_write_inode()\n -\u003e hfsplus_write_system_inode()\n -\u003e hfs_btree_write()\n -\u003e hfs_bnode_find(tree, 0)\n -\u003e __hfs_bnode_create(tree, 0)\n\nThread B:\n hfsplus_create_cat()\n -\u003e hfs_brec_insert()\n -\u003e hfs_bnode_split()\n -\u003e hfs_bmap_alloc()\n -\u003e hfs_bnode_find(tree, 0)\n -\u003e __hfs_bnode_create(tree, 0)\n\nIn this case, thread A creates the bnode, sets refcnt=1, and hashes it.\nThread B also tries to create the same bnode, notices it has already\nbeen inserted, drops its own instance, and uses the hashed one without\ngetting the node.\n\n```\n\n\tnode2 = hfs_bnode_findhash(tree, cnid);\n\tif (!node2) { \u003c- Thread A\n\t\thash = hfs_bnode_hash(cnid);\n\t\tnode-\u003enext_hash = tree-\u003enode_hash[hash];\n\t\ttree-\u003enode_hash[hash] = node;\n\t\ttree-\u003enode_hash_cnt++;\n\t} else { \u003c- Thread B\n\t\tspin_unlock(\u0026tree-\u003ehash_lock);\n\t\tkfree(node);\n\t\twait_event(node2-\u003elock_wq,\n\t\t\t!test_bit(HFS_BNODE_NEW, \u0026node2-\u003eflags));\n\t\treturn node2;\n\t}\n```\n\nHowever, hfs_bnode_find() requires each call to take a reference.\nHere both threads end up setting refcnt=1. When they later put the node,\nthis triggers:\n\nBUG_ON(!atomic_read(\u0026node-\u003erefcnt))\n\nIn this scenario, Thread B in fact finds the node in the hash table\nrather than creating a new one, and thus must take a reference.\n\nFix this by calling hfs_bnode_get() when reusing a bnode newly created by\nanother thread to ensure the refcount is updated correctly.\n\nA similar bug was fixed in HFS long ago in commit\na9dc087fd3c4 (\"fix missing hfs_bnode_get() in __hfs_bnode_create\")\nbut the same issue remained in HFS+ until now.",
"id": "GHSA-2wrv-52xx-6xxv",
"modified": "2026-07-30T06:32:26Z",
"published": "2026-01-13T18:31:03Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68774"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/152af114287851583cf7e0abc10129941f19466a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/39e149d58ef4d7883cbf87448d39d51292fd342d"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3b0fc7af50b896d0f3d104e70787ba1973bc0b56"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/457f795e7abd7770de10216d7f9994a3f12a56d6"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/5882e7c8cdbb5e254a69628b780acff89c78071e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b68dc4134b18a3922cd33439ec614aad4172bc86"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b9d1c6bb5f19460074ce9862cb80be86b5fb0a50"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.