hfsplus: fix missing hfs_bnode_get() in __hfs_bnode_create

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.