CVE-2026-45960

What it actually does

This is a local denial-of-service flaw in the Linux kernel HFS+ filesystem driver. When creating an HFS+ B-tree node, hfs_bnode_create() can encounter a node that is already present in the node hash, which should indicate filesystem corruption or an invalid allocation state. The vulnerable code returns that existing node without incrementing its reference count, creating a reference-count mismatch. When the node is later released through hfs_bnode_put(), the kernel can hit BUG_ON(!atomic_read(&node->refcnt)) in fs/hfsplus/bnode.c and panic, causing system-wide availability loss.

Why it matters to the business

Successful exploitation can crash an affected Linux host, causing service interruption, failed workloads, data processing disruption, and potential reboot or recovery activity. The risk is most relevant on systems that allow local users, removable media, disk images, loopback mounts, forensic workflows, backup/indexing tools, or automated processing of untrusted HFS+ filesystems. This issue is not listed in CISA KEV, is not flagged as ransomware-used, has very low EPSS, and has no stated public exploit maturity, so broad internet-scale exploitation is unlikely; however, the operational impact can still be high where an attacker can get a malformed HFS+ volume mounted on a critical system.

How an attack unfolds

An attacker first needs local access or a path to cause the target system to mount or inspect a crafted or corrupted HFS+ filesystem, such as a removable drive, disk image, loop device, or file handled by an automated analysis pipeline. The attacker prepares HFS+ metadata so that allocation state is inconsistent, for example causing a B-tree node that is already in use to appear available. When the Linux HFS+ driver processes the filesystem and hfs_bmap_alloc() attempts to allocate that node, hfs_bnode_create() encounters an already hashed node. In vulnerable kernels, it returns the existing node without taking an additional reference. Subsequent cleanup releases the node with an inconsistent reference count and triggers a kernel BUG in hfs_bnode_put(), resulting in a kernel panic and denial of service.

How to fix it

Upgrade to a kernel version from the relevant Linux distribution or vendor that includes the HFS+ fix changing hfs_bnode_create() to return ERR_PTR(-EEXIST) when a node already exists. No exact fixed package versions were provided in the input, so use vendor advisories, distribution security trackers, and kernel changelogs to identify the corrected build for each deployed kernel line. Where immediate patching is not possible, reduce exposure by disabling or blacklisting the hfsplus kernel module if HFS+ support is not required, restricting who can mount filesystems, disabling desktop/server auto-mounting for untrusted removable media, preventing unprivileged loop-device mounts, and processing untrusted disk images only in disposable sandboxes or virtual machines.

How to confirm the fix worked

Confirm that affected systems are running a vendor kernel build containing the HFS+ bnode_create fix. Validate configuration by checking whether the hfsplus module is loaded or loadable, whether HFS+ filesystems are mounted, and whether unprivileged users can mount removable media or loopback images. Review kernel package versions against vendor security advisories because fixed versions vary by distribution. If mitigation is used instead of patching, verify that hfsplus cannot be loaded automatically, untrusted HFS+ media is not auto-mounted, and mount permissions require appropriate administrative control. In a controlled non-production test environment, a regression test using a corrupted HFS+ image should fail gracefully rather than causing a kernel BUG or panic.

Typical attack path

1. Obtain local execution capability or a way to influence the system into mounting or scanning an HFS+ filesystem.
2. Create or supply a malformed HFS+ volume with inconsistent B-tree node allocation metadata.
3. Cause the affected Linux kernel to mount, auto-mount, inspect, or otherwise parse the HFS+ filesystem.
4. Trigger HFS+ B-tree node allocation so hfs_bnode_create() encounters a node that is already hashed.
5. Exploit the reference-count inconsistency caused by returning the existing node without incrementing its reference count.
6. Cause hfs_bnode_put() to hit the kernel BUG condition, leading to kernel panic and host denial of service.

How to detect it

Look for evidence of kernel crashes or panics associated with the HFS+ filesystem driver. Useful sources include systemd-journald, /var/log/kern.log, /var/log/messages, dmesg output, kdump/vmcore data, auditd mount and module-loading events, udev/removable-media events, EDR telemetry, shell history, and logs from tools that mount or inspect disk images. Focus on panics containing fs/hfsplus/bnode.c, hfs_bnode_put(), hfs_bnode_create(), hfs_bmap_alloc(), or BUG_ON reference-count messages. Correlate crash timing with mount activity for HFS+ volumes, loop device setup, losetup use, modprobe of hfsplus, insertion of removable media, or automated processing of disk images. Because this is a denial-of-service issue, evidence may be limited to pre-crash logs and crash dumps; preservation of vmcore and the triggering filesystem image is important for confirmation.

• kernel BUG at fs/hfsplus/bnode.c:676
• BUG_ON(!atomic_read(&node->refcnt))
• hfs_bnode_put
• hfs_bnode_create
• hfs_bmap_alloc
• fs/hfsplus/bnode.c
• hfsplus
• modprobe hfsplus
• mount -t hfsplus
• type=hfsplus
• losetup
• /var/crash
• /proc/modules

What your security team should do

• Prioritize patching systems that allow removable media, user-controlled mounts, loop devices, disk image processing, forensic tooling, backup indexing, or multi-user shell access.
• Inventory systems with the hfsplus module loaded or available and determine whether HFS+ support is operationally required.
• Disable or blacklist hfsplus on servers and production systems where Mac-formatted HFS+ volume support is unnecessary.
• Restrict mount privileges and disable automatic mounting of untrusted removable media or disk images.
• Review crash, kernel, and audit logs for prior kernel panics involving hfsplus, hfs_bnode_put(), hfs_bnode_create(), or fs/hfsplus/bnode.c.
• If crashes are observed, preserve kdump/vmcore data, kernel logs, mount history, and the associated disk image or removable media for forensic analysis.
• Treat repeated unexplained panics shortly after HFS+ mounts as potential exploitation or malformed-media abuse, even though current public exploitation likelihood is low.