CVE-2025-68774 Overview
A race condition vulnerability has been identified in the Linux kernel's HFS+ (hfsplus) filesystem implementation. The flaw exists in the __hfs_bnode_create function where concurrent sync() and link() operations can lead to improper reference counting of B-tree nodes (bnodes), ultimately triggering a kernel panic through a BUG_ON assertion failure.
Critical Impact
This vulnerability can cause kernel crashes and system instability when HFS+ filesystems are mounted, potentially leading to denial of service conditions on affected Linux systems.
Affected Products
- Linux kernel (HFS+ filesystem module)
- Systems mounting HFS+ formatted volumes
- Linux distributions with HFS+ filesystem support enabled
Discovery Timeline
- January 13, 2026 - CVE-2025-68774 published to NVD
- January 13, 2026 - Last updated in NVD database
Technical Details for CVE-2025-68774
Vulnerability Analysis
The vulnerability is a classic race condition in the HFS+ B-tree node management subsystem. When two kernel threads simultaneously attempt to find or create the same bnode through hfs_bnode_find(), both may independently determine that the node does not exist in the hash table and proceed to create it. This occurs because the hash lookup and node creation are not performed atomically.
The problematic scenario unfolds as follows: Thread A (executing hfsplus_write_inode() → hfs_btree_write() → hfs_bnode_find()) creates a bnode, sets its reference count to 1, and inserts it into the hash table. Concurrently, Thread B (executing hfsplus_create_cat() → hfs_brec_insert() → hfs_bmap_alloc() → hfs_bnode_find()) may have already passed the initial hash check before Thread A's insertion completed. When Thread B later discovers the newly-hashed node from Thread A, it reuses it but fails to increment the reference count.
This results in both threads sharing a bnode with a reference count of only 1. When both threads subsequently release their references via hfs_bnode_put(), the second decrement triggers a BUG_ON(!atomic_read(&node->refcnt)) assertion, causing a kernel panic.
Root Cause
The root cause is a missing hfs_bnode_get() call in the code path where Thread B discovers that another thread has already created and hashed the bnode. The existing code correctly frees Thread B's unused local node and waits for the new node to be fully initialized, but it neglects to acquire a proper reference to the shared bnode before returning it. This is a Time-of-Check Time-of-Use (TOCTOU) race condition combined with improper reference counting.
Notably, an identical bug was previously fixed in the HFS filesystem (not HFS+) in commit a9dc087fd3c4 ("fix missing hfs_bnode_get() in __hfs_bnode_create"), but the HFS+ implementation was not updated at that time, leaving it vulnerable.
Attack Vector
The vulnerability can be triggered through normal filesystem operations on HFS+ mounted volumes. An attacker with local access to a system with an HFS+ filesystem mounted could potentially trigger the race condition by executing concurrent filesystem operations, leading to a kernel panic and denial of service.
The attack does not require elevated privileges beyond basic filesystem access. Systems that automatically mount HFS+ volumes (such as those mounting Apple-formatted external drives or disk images) are particularly at risk.
Detection Methods for CVE-2025-68774
Indicators of Compromise
- Kernel panic messages containing BUG_ON(!atomic_read(&node->refcnt))
- System crashes or unexpected reboots when accessing HFS+ filesystems
- Kernel log entries indicating hfsplus module failures or reference count errors
- Hung or unresponsive systems during HFS+ filesystem write operations
Detection Strategies
- Monitor kernel logs (dmesg, /var/log/kern.log) for BUG_ON assertions from hfsplus module
- Implement crash dump analysis to identify hfsplus-related kernel panics
- Deploy kernel tracing to monitor hfs_bnode_find() and __hfs_bnode_create function calls for anomalies
- Use kernel debugging tools to track reference count operations on bnode structures
Monitoring Recommendations
- Enable kernel crash dumps and configure automatic analysis for hfsplus-related failures
- Monitor system stability metrics on servers with HFS+ filesystems mounted
- Implement alerting for unexpected system reboots that may indicate kernel crashes
- Review audit logs for concurrent filesystem operations targeting HFS+ volumes
How to Mitigate CVE-2025-68774
Immediate Actions Required
- Update the Linux kernel to a patched version containing the fix
- Consider unmounting HFS+ filesystems on critical systems until patches are applied
- Restrict access to HFS+ mounted volumes to trusted users only
- Monitor systems with HFS+ mounts for signs of instability
Patch Information
The Linux kernel maintainers have released patches to address this vulnerability. The fix adds a hfs_bnode_get() call when reusing a bnode that was newly created by another thread, ensuring the reference count is properly incremented.
The following commits contain the fix:
- Linux Kernel Commit 152af11
- Linux Kernel Commit 457f79e
- Linux Kernel Commit 5882e7c
- Linux Kernel Commit b68dc41
- Linux Kernel Commit b9d1c6b
Workarounds
- Unmount all HFS+ filesystems on affected systems until patching is complete
- Disable the hfsplus kernel module if not required: modprobe -r hfsplus
- Use alternative filesystems (ext4, XFS, etc.) for critical data storage
- Implement access controls to prevent untrusted users from mounting HFS+ volumes
# Disable hfsplus module loading
echo "blacklist hfsplus" >> /etc/modprobe.d/blacklist-hfsplus.conf
echo "install hfsplus /bin/false" >> /etc/modprobe.d/blacklist-hfsplus.conf
# Unload the module if currently loaded
modprobe -r hfsplus
# Verify module is not loaded
lsmod | grep hfsplus
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

