CVE-2025-68774: Linux Kernel Race Condition Vulnerability

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:

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

bash

# 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