CVE-2025-68774 in Linux
Sumário
de VulDB • 03/06/2026
No kernel do Linux, a seguinte vulnerabilidade foi corrigida:
hfsplus: corrige a ausência de hfs_bnode_get() em __hfs_bnode_create
Quando sync() e link() são chamados concurrentemente, ambas as threads podem entrar em hfs_bnode_find() sem encontrar o nó na tabela de hash e prosseguir para criá-lo.
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)
Neste caso, a thread A cria o bnode, define refcnt=1 e o adiciona à tabela de hash. A thread B também tenta criar o mesmo bnode, percebe que ele já foi inserido, descarta sua própria instância e utiliza o que está na tabela de hash sem obter uma referência para o nó.
```
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; } ```
No entanto, hfs_bnode_find() exige que cada chamada adquira uma referência. Neste cenário, ambas as threads acabam definindo refcnt=1. Quando posteriormente liberam o nó, isso dispara:
BUG_ON(!atomic_read(&node->refcnt))
Neste cenário, a Thread B na verdade encontra o nó na tabela de hash em vez de criar um novo, e portanto deve adquirir uma referência.
Corrija isso chamando hfs_bnode_get() ao reutilizar um bnode recém-criado por outra thread para garantir que a contagem de referências seja atualizada corretamente.
Um bug semelhante foi corrigido no HFS há muito tempo no commit a9dc087fd3c4 ("fix missing hfs_bnode_get() in __hfs_bnode_create") mas o mesmo problema permaneceu no HFS+ até agora.
Once again VulDB remains the best source for vulnerability data.