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.
Published: 2026-01-13
Score: 5.5 Medium
EPSS: < 1% Very Low
KEV: No
Impact: n/a
Action: n/a
AI Analysis

Analysis and contextual insights are available on OpenCVE Cloud.

Remediation

No vendor fix or workaround currently provided.

Additional remediation guidance may be available on OpenCVE Cloud.

Tracking

Sign in to view the affected projects.

Advisories
Source ID Title
Debian DLA Debian DLA DLA-4475-1 linux security update
Debian DLA Debian DLA DLA-4476-1 linux-6.1 security update
Debian DSA Debian DSA DSA-6126-1 linux security update
Debian DSA Debian DSA DSA-6127-1 linux security update
Ubuntu USN Ubuntu USN USN-8096-1 Linux kernel vulnerabilities
Ubuntu USN Ubuntu USN USN-8096-2 Linux kernel (FIPS) vulnerabilities
Ubuntu USN Ubuntu USN USN-8096-3 Linux kernel vulnerabilities
Ubuntu USN Ubuntu USN USN-8096-4 Linux kernel (Real-time) vulnerabilities
Ubuntu USN Ubuntu USN USN-8096-5 Linux kernel (NVIDIA Tegra IGX) vulnerabilities
Ubuntu USN Ubuntu USN USN-8116-1 Linux kernel (Intel IoTG Real-time) vulnerabilities
Ubuntu USN Ubuntu USN USN-8141-1 Linux kernel (Raspberry Pi) vulnerabilities
Ubuntu USN Ubuntu USN USN-8163-1 Linux kernel (Azure FIPS) vulnerabilities
Ubuntu USN Ubuntu USN USN-8163-2 Linux kernel (Azure) vulnerabilities
Ubuntu USN Ubuntu USN USN-8177-1 Linux kernel vulnerabilities
Ubuntu USN Ubuntu USN USN-8179-1 Linux kernel vulnerabilities
Ubuntu USN Ubuntu USN USN-8177-2 Linux kernel (Real-time) vulnerabilities
Ubuntu USN Ubuntu USN USN-8183-1 Linux kernel (GCP) vulnerabilities
Ubuntu USN Ubuntu USN USN-8184-1 Linux kernel (Real-time) vulnerabilities
Ubuntu USN Ubuntu USN USN-8179-2 Linux kernel (FIPS) vulnerabilities
Ubuntu USN Ubuntu USN USN-8185-1 Linux kernel (NVIDIA) vulnerabilities
Ubuntu USN Ubuntu USN USN-8179-3 Linux kernel vulnerabilities
Ubuntu USN Ubuntu USN USN-8183-2 Linux kernel vulnerabilities
Ubuntu USN Ubuntu USN USN-8203-1 Linux kernel (Oracle) vulnerabilities
Ubuntu USN Ubuntu USN USN-8204-1 Linux kernel (Raspberry Pi Real-time) vulnerabilities
Ubuntu USN Ubuntu USN USN-8185-2 Linux kernel (Low Latency NVIDIA) vulnerabilities
Ubuntu USN Ubuntu USN USN-8179-4 Linux kernel (GCP) vulnerabilities
Ubuntu USN Ubuntu USN USN-8243-1 Linux kernel (Azure) vulnerabilities
Ubuntu USN Ubuntu USN USN-8245-1 Linux kernel vulnerabilities
Ubuntu USN Ubuntu USN USN-8257-1 Linux kernel (Raspberry Pi) vulnerabilities
Ubuntu USN Ubuntu USN USN-8258-1 Linux kernel (Azure) vulnerabilities
Ubuntu USN Ubuntu USN USN-8260-1 Linux kernel (Azure FIPS) vulnerabilities
Ubuntu USN Ubuntu USN USN-8261-1 Linux kernel (Xilinx) vulnerabilities
Ubuntu USN Ubuntu USN USN-8265-1 Linux kernel (NVIDIA Tegra) vulnerabilities
History

Mon, 19 Jan 2026 12:45:00 +0000


Thu, 15 Jan 2026 12:15:00 +0000

Type Values Removed Values Added
References
Metrics threat_severity

None

cvssV3_1

{'score': 5.5, 'vector': 'CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H'}

threat_severity

Moderate


Tue, 13 Jan 2026 15:45:00 +0000

Type Values Removed Values Added
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.
Title hfsplus: fix missing hfs_bnode_get() in __hfs_bnode_create
First Time appeared Linux
Linux linux Kernel
CPEs cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
Vendors & Products Linux
Linux linux Kernel
References

Subscriptions

Linux Linux Kernel
cve-icon MITRE

Status: PUBLISHED

Assigner: Linux

Published:

Updated: 2026-05-11T21:53:05.691Z

Reserved: 2025-12-24T10:30:51.035Z

Link: CVE-2025-68774

cve-icon Vulnrichment

No data.

cve-icon NVD

Status : Deferred

Published: 2026-01-13T16:15:56.960

Modified: 2026-04-15T00:35:42.020

Link: CVE-2025-68774

cve-icon Redhat

Severity : Moderate

Publid Date: 2026-01-13T00:00:00Z

Links: CVE-2025-68774 - Bugzilla

cve-icon OpenCVE Enrichment

No data.

Weaknesses

No weakness.