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.
Product status
1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 (git) before 3b0fc7af50b896d0f3d104e70787ba1973bc0b56
1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 (git) before 39e149d58ef4d7883cbf87448d39d51292fd342d
1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 (git) before b68dc4134b18a3922cd33439ec614aad4172bc86
1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 (git) before b9d1c6bb5f19460074ce9862cb80be86b5fb0a50
1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 (git) before 457f795e7abd7770de10216d7f9994a3f12a56d6
1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 (git) before 5882e7c8cdbb5e254a69628b780acff89c78071e
1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 (git) before 152af114287851583cf7e0abc10129941f19466a
2.6.12
Any version before 2.6.12
5.10.248 (semver)
5.15.198 (semver)
6.1.160 (semver)
6.6.120 (semver)
6.12.64 (semver)
6.18.3 (semver)
6.19 (original_commit_for_fix)
References
git.kernel.org/...c/3b0fc7af50b896d0f3d104e70787ba1973bc0b56
git.kernel.org/...c/39e149d58ef4d7883cbf87448d39d51292fd342d
git.kernel.org/...c/b68dc4134b18a3922cd33439ec614aad4172bc86
git.kernel.org/...c/b9d1c6bb5f19460074ce9862cb80be86b5fb0a50
git.kernel.org/...c/457f795e7abd7770de10216d7f9994a3f12a56d6
git.kernel.org/...c/5882e7c8cdbb5e254a69628b780acff89c78071e
git.kernel.org/...c/152af114287851583cf7e0abc10129941f19466a