HarborGuardharborguardDatabase
Back to search
HIGHCVE-2026-46299Published Modified CNA Linux

CVE-2026-46299: hfsplus: fix held lock freed on hfsplus_fill_super()

In the Linux kernel, the following vulnerability has been resolved: hfsplus: fix held lock freed on hfsplus_fill_super() hfsplus_fill_super() calls hfs_find_init() to initialize a search structure, which acquires tree->tree_lock. If the subsequent call to hfsplus_cat_build_key() fails, the function jumps to the out_put_root error label without releasing the lock. The later cleanup path then frees the tree data structure with the lock still held, triggering a held lock freed warning. Fix this by adding the missing hfs_find_exit(&fd) call before jumping to the out_put_root error label. This ensures that tree->tree_lock is properly released on the error path. The bug was originally detected on v6.13-rc1 using an experimental static analysis tool we are developing, and we have verified that the issue persists in the latest mainline kernel. The tool is specifically designed to detect memory management issues. It is currently under active development and not yet publicly available. We confirmed the bug by runtime testing under QEMU with x86_64 defconfig, lockdep enabled, and CONFIG_HFSPLUS_FS=y. To trigger the error path, we used GDB to dynamically shrink the max_unistr_len parameter to 1 before hfsplus_asc2uni() is called. This forces hfsplus_asc2uni() to naturally return -ENAMETOOLONG, which propagates to hfsplus_cat_build_key() and exercises the faulty error path. The following warning was observed during mount: ========================= WARNING: held lock freed! 7.0.0-rc3-00016-gb4f0dd314b39 #4 Not tainted ------------------------- mount/174 is freeing memory ffff888103f92000-ffff888103f92fff, with a lock still held there! ffff888103f920b0 (&tree->tree_lock){+.+.}-{4:4}, at: hfsplus_find_init+0x154/0x1e0 2 locks held by mount/174: #0: ffff888103f960e0 (&type->s_umount_key#42/1){+.+.}-{4:4}, at: alloc_super.constprop.0+0x167/0xa40 #1: ffff888103f920b0 (&tree->tree_lock){+.+.}-{4:4}, at: hfsplus_find_init+0x154/0x1e0 stack backtrace: CPU: 2 UID: 0 PID: 174 Comm: mount Not tainted 7.0.0-rc3-00016-gb4f0dd314b39 #4 PREEMPT(lazy) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0x82/0xd0 debug_check_no_locks_freed+0x13a/0x180 kfree+0x16b/0x510 ? hfsplus_fill_super+0xcb4/0x18a0 hfsplus_fill_super+0xcb4/0x18a0 ? __pfx_hfsplus_fill_super+0x10/0x10 ? srso_return_thunk+0x5/0x5f ? bdev_open+0x65f/0xc30 ? srso_return_thunk+0x5/0x5f ? pointer+0x4ce/0xbf0 ? trace_contention_end+0x11c/0x150 ? __pfx_pointer+0x10/0x10 ? srso_return_thunk+0x5/0x5f ? bdev_open+0x79b/0xc30 ? srso_return_thunk+0x5/0x5f ? srso_return_thunk+0x5/0x5f ? vsnprintf+0x6da/0x1270 ? srso_return_thunk+0x5/0x5f ? __mutex_unlock_slowpath+0x157/0x740 ? __pfx_vsnprintf+0x10/0x10 ? srso_return_thunk+0x5/0x5f ? srso_return_thunk+0x5/0x5f ? mark_held_locks+0x49/0x80 ? srso_return_thunk+0x5/0x5f ? srso_return_thunk+0x5/0x5f ? irqentry_exit+0x17b/0x5e0 ? trace_irq_disable.constprop.0+0x116/0x150 ? __pfx_hfsplus_fill_super+0x10/0x10 ? __pfx_hfsplus_fill_super+0x10/0x10 get_tree_bdev_flags+0x302/0x580 ? __pfx_get_tree_bdev_flags+0x10/0x10 ? vfs_parse_fs_qstr+0x129/0x1a0 ? __pfx_vfs_parse_fs_qstr+0x3/0x10 vfs_get_tree+0x89/0x320 fc_mount+0x10/0x1d0 path_mount+0x5c5/0x21c0 ? __pfx_path_mount+0x10/0x10 ? trace_irq_enable.constprop.0+0x116/0x150 ? trace_irq_enable.constprop.0+0x116/0x150 ? srso_return_thunk+0x5/0x5f ? srso_return_thunk+0x5/0x5f ? kmem_cache_free+0x307/0x540 ? user_path_at+0x51/0x60 ? __x64_sys_mount+0x212/0x280 ? srso_return_thunk+0x5/0x5f __x64_sys_mount+0x212/0x280 ? __pfx___x64_sys_mount+0x10/0x10 ? srso_return_thunk+0x5/0x5f ? trace_irq_enable.constprop.0+0x116/0x150 ? srso_return_thunk+0x5/0x5f do_syscall_64+0x111/0x680 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7ffacad55eae Code: 48 8b 0d 85 1f 0f 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 49 89 ca b8 a5 00 00 8 RSP: 002b ---truncated---

Metrics

CVSS v3.1
7.0
Severity
HIGH
Fixed in
0
Affected Products
2

Get notified

Email me when this CVE is updated: new fix versions, severity changes, or any record change.

HarborGuard Analysis

Synopsis

This is a lock-management bug in the Linux kernel's HFS+ filesystem driver (hfsplus). During filesystem mount, if a specific error path is triggered inside hfsplus_fill_super(), a tree lock (tree->tree_lock) is acquired but never released before the underlying memory structure is freed, producing a held-lock-freed kernel warning. The vulnerability requires a local low-privilege account and elevated attack complexity to trigger, but successful exploitation gives the attacker full read, write, and crash capabilities on the affected system. Patched-image rebuilds at versions 6.6.140 and 6.12.88 are available on HarborGuard for environments running affected kernel versions.

HarborGuard Coverage

Detection

Detection is available across every HarborGuard environment: the CVE is ingested from upstream Linux kernel security feeds within minutes of publication and matched against customer images, including custom-built base images that bundle affected kernel versions. Any image whose kernel version falls within the affected range is flagged automatically in registry scans and CI/CD pipeline checks.

Available
Triage

HarborGuard scores this CVE at 7.0 HIGH using the CVSS v3.1 vector and weights findings against each customer organization's compliance policy to determine urgency and routing. Triage results are surfaced to the team inbox or ticketing integration configured for each environment, so the right engineering group sees the alert without manual sorting.

Available
Patch

A patched-image rebuild at kernel versions 6.6.140 or 6.12.88 becomes available on HarborGuard for any environment found running an affected image. For customers who opt into auto-remediation, HarborGuard triggers a rebuild, runs a regression test suite, and opens a pull request against affected workloads automatically.

Available

Exploit Conditions

  • Network reachabilityNot required

    The attacker needs an existing shell or process on the host; no network exposure is required to reach the vulnerable code path.

  • AuthenticationRequired

    Any low-privilege local account is sufficient to attempt the exploit; no administrative credentials are needed.

  • Victim interactionNot required

    No user interaction is required; the attacker can trigger the vulnerable mount path without involving another user.

  • Attack complexityDetail

    Attack complexity is high, meaning the attacker must engineer specific environmental conditions (such as manipulating filesystem parameters) to force the faulty error path during mount.

Blast Radius

  • A successful exploit gives the attacker full read access to kernel memory in the affected address space, exposing stored credentials, cryptographic keys, and other sensitive in-memory data.
  • The attacker gains write capability over kernel data structures, enabling modification of security controls, filesystem metadata, or process privileges.
  • The attacker can crash the affected system by triggering a kernel panic through the lock-freed memory condition, causing a denial of service.
  • Any container or workload sharing the host kernel is exposed if the kernel is compromised through this path.

How HarborGuard Handles This

Available on HarborGuard: detection for CVE-2026-46299 runs on every image scan and pipeline check, matching kernel version metadata against the affected range for both upstream base images and custom-built images. Where auto-remediation is enabled and compliance policy permits, HarborGuard triggers a patched-image rebuild at Linux kernel 6.6.140 or 6.12.88, runs a regression test suite against the rebuilt image, and opens a pull request against the affected workload. For high-severity issues, the median time from CVE publication to a merged patch PR is around 90 minutes for environments with auto-remediation enabled. For environments that cannot immediately rebuild (for example, those subject to change-control windows), HarborGuard recommends applying kernel lockdown or restricting HFS+ filesystem mount privileges via Linux security module policy as a compensating control while the rebuild is staged.

See how HarborGuard automates this

Fix available

0041acda6d9f96006703466449c10c9a69590c8b93ca80e3012c8be85b4f8d0d20eac8d3b17ff257e6.6.1406.12.886.18.307.0.77.1-rc190c500e4fd83fa33c09bc7ee23b6d9cc487ac733bfbcce6a7b0552a390620d9b2c4d2bcb1825cbdcd309d3308de658d87c42d97e044c89a226327526
Affected packages
  • Linux / Linux
    < 3ca80e3012c8be85b4f8d0d20eac8d3b17ff257e (from 89ac9b4d3d1a049ae1054f99b1aed81092cd0a82) · < 041acda6d9f96006703466449c10c9a69590c8b9 (from 89ac9b4d3d1a049ae1054f99b1aed81092cd0a82) · < d309d3308de658d87c42d97e044c89a226327526 (from 89ac9b4d3d1a049ae1054f99b1aed81092cd0a82) · < bfbcce6a7b0552a390620d9b2c4d2bcb1825cbdc (from 89ac9b4d3d1a049ae1054f99b1aed81092cd0a82) · < 90c500e4fd83fa33c09bc7ee23b6d9cc487ac733 (from 89ac9b4d3d1a049ae1054f99b1aed81092cd0a82)
  • Linux / Linux
    3.19
    Fixed in 0, 6.6.140, 6.12.88, 6.18.30, 7.0.7, 7.1-rc1
CVSS Vector
CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H