CVE-2026-46299

What it actually does

This is a Linux kernel HFS Plus filesystem error-path bug in hfsplus_fill_super(). During HFS+ mount handling, hfs_find_init() acquires tree->tree_lock, but if hfsplus_cat_build_key() fails, the cleanup path can free the HFS+ tree structure while its lock is still held. Freeing memory that still contains an acquired lock violates kernel locking and memory-management invariants and can lead to kernel warnings, instability, denial of service, or potentially broader memory-corruption consequences depending on kernel configuration and execution context. Exploitation is local, requires the ability to invoke or influence mounting of an HFS+ filesystem image, and is considered high complexity based on the provided CVSS vector. No public exploit maturity or known exploitation is indicated, and the EPSS score is very low.

Why it matters to the business

Systems that allow users, containers, removable media workflows, forensic tooling, backup tooling, or automated file-ingestion services to mount untrusted HFS+ images could be exposed to local kernel instability or compromise risk. The most likely operational impact is a kernel warning, crash, or denial of service during mount processing, but the assigned severity also reflects potential confidentiality and integrity impact if the memory-corruption condition were weaponized. Because the issue is in the kernel, successful exploitation can affect the entire host rather than only the mounting process. It is not listed in CISA KEV, is not reported as ransomware-used, and has no known mature exploit in the provided data, so remediation should be prioritized based on whether HFS+ mounting is enabled or reachable in the organization.

How an attack unfolds

An attacker first needs local execution or a path to cause the target system to mount attacker-controlled HFS+ filesystem data. They provide a malformed or specially crafted HFS+ volume intended to drive hfsplus_fill_super() into an error path after hfs_find_init() has acquired the catalog tree lock. When hfsplus_cat_build_key() fails, the vulnerable kernel path skips hfs_find_exit(), leaving tree->tree_lock held. Kernel cleanup then frees the tree structure while the lock remains held, triggering a held-lock-freed condition. In debug or lockdep-enabled kernels this is visible as a kernel warning; in production kernels, the practical effect may be a crash, hang, or other instability. A reliable exploit would need to shape the mount failure path and kernel memory state, which is why the attack complexity is high. There are no named threat actors or active campaigns provided for this vulnerability.

How to fix it

Upgrade the Linux kernel to a vendor release that includes the upstream fix adding the missing hfs_find_exit(&fd) call before the out_put_root cleanup path in hfsplus_fill_super(). Because no exact affected product list or fixed package versions were provided, use the relevant distribution vendor advisory and kernel changelog to identify the corrected kernel build for each platform. Where immediate patching is not possible, reduce exposure by disabling or blocking HFS+ filesystem mounting if not required, unloading or blacklisting the hfsplus kernel module where feasible, restricting mount privileges, preventing unprivileged filesystem mounts, and avoiding automated mounting of untrusted disk images or removable media. In containerized environments, avoid granting CAP_SYS_ADMIN or device access that permits mounting untrusted filesystems.

How to confirm the fix worked

Confirm that systems are running a kernel build containing the HFS+ fix for hfsplus_fill_super(). Validate through vendor package metadata, kernel changelogs, or source inspection showing that hfs_find_exit(&fd) is called on the hfsplus_cat_build_key() failure path before jumping to out_put_root. Check whether CONFIG_HFSPLUS_FS is enabled or whether the hfsplus module is present and loadable. Confirm mitigations by verifying that unprivileged users cannot mount filesystems, that hfsplus is not loaded when not needed, and that module blacklist or policy controls prevent HFS+ mounts. For exposure testing, review whether workflows automatically mount uploaded disk images, removable media, backup volumes, or forensic images using HFS+. Avoid testing with untrusted proof-of-concept images on production systems.

Typical attack path

1. Obtain local code execution, shell access, or another mechanism that can cause the host to mount an HFS+ filesystem image.
2. Prepare or supply an HFS+ volume/image that triggers an error in hfsplus_cat_build_key() during hfsplus_fill_super().
3. Invoke a mount operation using the hfsplus filesystem driver, directly or through an automated media/file-processing workflow.
4. Drive the vulnerable error path where hfs_find_init() has acquired tree->tree_lock but hfs_find_exit() is not called before cleanup.
5. Cause the kernel to free the HFS+ tree structure while the lock is still held, resulting in a held-lock-freed condition.
6. Leverage the resulting kernel instability for denial of service, or attempt further memory-corruption exploitation if feasible on the target kernel build.

How to detect it

To determine whether this was already triggered, review kernel logs, persistent journal logs, audit logs, crash dumps, and endpoint telemetry for HFS+ mount activity followed by kernel lock or memory-management warnings. Useful sources include dmesg, /var/log/kern.log, /var/log/messages, journalctl -k, auditd records for mount syscalls, EDR process telemetry for mount utilities, and kdump/vmcore artifacts after unexpected reboots. Look for mount attempts using filesystem type hfsplus, especially against removable media, loop devices, disk images, or user-writable paths. Correlate these events with warnings such as "held lock freed", stack frames containing hfsplus_fill_super(), hfsplus_find_init(), hfsplus_cat_build_key(), kfree(), get_tree_bdev_flags(), path_mount(), or __x64_sys_mount. Since no public exploit indicators or threat-actor-specific artifacts are provided, detection should focus on behavioral evidence: unexpected HFS+ mounts, failed HFS+ mounts, kernel warnings, crashes, and suspicious local users or services initiating mount operations.

• WARNING: held lock freed!
• mount is freeing memory
• with a lock still held
• &tree->tree_lock
• hfsplus_fill_super
• hfsplus_find_init
• hfs_find_init
• hfs_find_exit
• hfsplus_cat_build_key
• hfsplus_asc2uni
• get_tree_bdev_flags
• vfs_get_tree
• path_mount
• __x64_sys_mount
• type=hfsplus
• fstype=hfsplus
• mount -t hfsplus
• CONFIG_HFSPLUS_FS=y

What your security team should do

• Inventory Linux systems where HFS+ support is enabled, loadable, or used by removable media, forensic, backup, or image-processing workflows.
• Prioritize kernel updates for systems that allow local users, containers, automation, or services to mount HFS+ filesystems or process untrusted disk images.
• If patching is delayed, disable or blacklist the hfsplus module where business use is not required.
• Restrict mount capability to trusted administrators; remove CAP_SYS_ADMIN from containers and services that do not explicitly require it.
• Disable unprivileged filesystem mounts and review automount rules for removable media or uploaded images.
• Monitor kernel logs for held-lock-freed warnings and HFS+ mount failures, especially on shared, multi-user, or image-processing hosts.
• Review audit logs for unexpected hfsplus mount attempts by non-administrative users or service accounts.
• Use crash dump and kernel log retention on exposed systems to preserve evidence if exploitation causes instability or reboot.
• Track distribution advisories for exact fixed kernel package versions because fixed_versions were not provided in the input.