CVE-2026-46299 json
hfsplus: fix held lock freed on hfsplus_fill_super()
published 2026-06-08 5 mo ago modified 2026-08-05 3 mo ago also EUVD-2026-35165
- cvss
- 7.0
- version 3.1, CNA
- cisa kev
- Not listed
- not in CISA's catalog
- epss
- 0.1%
- EPSS 0.1% chance of exploitation in 30 days, percentile 0%
- public exploits
- 0
- none known
Summary
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---
Patch / fix
- Linux Linux 5.10.259, 5.15.210, 6.1.176, 6.6.140, 6.12.88, 6.18.30, 7.0.7, 7.1
- linux Debian 12 6.1.176-1
- linux Debian 13 6.12.88-1
- linux Debian 14 7.0.7-1
debian advisories DEBIAN-CVE-2026-46299
- linux Ubuntu 22.04 LTS 5.15.0-198.208
- linux Ubuntu 24.04 LTS 6.8.0-136.136
- linux Ubuntu 26.04 LTS 7.0.0-28.28
- linux-aws Ubuntu 22.04 LTS 5.15.0-1117.124
- linux-aws Ubuntu 24.04 LTS 6.8.0-1061.64
- linux-aws Ubuntu 26.04 LTS 7.0.0-1009.9
- linux-gcp Ubuntu 22.04 LTS 5.15.0-1118.128
- linux-gcp Ubuntu 24.04 LTS 6.8.0-1064.72
ubuntu advisories UBUNTU-CVE-2026-46299
Ubuntu security data © Canonical Ltd., from https://github.com/canonical/ubuntu-security-notices via OSV; changed: normalised to fixed package versions per release. CC BY-SA 4.0
- kernel-syms SLES LTSS Extended Security 12 SP5, SLES 12 SP5-LTSS 4.12.14-122.320.1
- kernel-source SLES LTSS Extended Security 12 SP5, SLES 12 SP5-LTSS 4.12.14-122.320.1
- kernel-default SLES LTSS Extended Security 12 SP5, SLES 12 SP5-LTSS, SLE Live Patching 12 SP5 4.12.14-122.320.1
- kgraft-patch-SLE12-SP5_Update_85 SLE Live Patching 12 SP5 1-8.3.1
suse advisories SUSE-SU-2026:2914-1
- kernel-source openSUSE Tumbleweed 7.0.12-1.1
opensuse advisories openSUSE-SU-2026:11014-1
- git.kernel.org/stable/c/e890656accee4c26d932ea388eb8936a6e22184d commit
- git.kernel.org/stable/c/6499c9c8ec437a369e7e221dad91f6122b50759d commit
- git.kernel.org/stable/c/c554ddc87af4d4e4be42f8aed1baec9e1c7588e0 commit
- git.kernel.org/stable/c/3ca80e3012c8be85b4f8d0d20eac8d3b17ff257e commit
- git.kernel.org/stable/c/041acda6d9f96006703466449c10c9a69590c8b9 commit
- git.kernel.org/stable/c/d309d3308de658d87c42d97e044c89a226327526 commit
- git.kernel.org/stable/c/bfbcce6a7b0552a390620d9b2c4d2bcb1825cbdc commit
- git.kernel.org/stable/c/90c500e4fd83fa33c09bc7ee23b6d9cc487ac733 commit
Vendor advisories
What the vendors themselves say about their products: affected, fixed or not affected, and what to do.
red hat product security vex CVE-2026-46299 updated cvss 5.5
kernel: hfsplus: fix held lock freed on hfsplus_fill_super()
-
Red Hat Enterprise Linux 6 perf, kernel, python-perf, kernel-kdump, kernel-firmware, kernel-bootwrapper, +1 moreaffected: no fix planned “Out of support scope”
-
Red Hat Enterprise Linux 7 perf, kernel, bpftool, kernel-rt, python-perf, kernel-kdump, +8 more Red Hat Enterprise Linux 8 perf, kernel, bpftool, kernel-rt, kernel-core, kernel-tools, +29 more Red Hat Enterprise Linux 9 rv, perf, rtla, kernel, bpftool, libperf, +83 more Red Hat Enterprise Linux 10 kernelnot affected: vulnerable code not present
Red Hat CSAF VEX © Red Hat, Inc., from https://security.access.redhat.com/data/csaf/v2/vex/; changed: reduced to product statuses and remediations. CC BY 4.0 · csaf
Exploit prediction
0.09% chance of exploitation in the next 30 days, higher than 0% of all scored CVEs (FIRST EPSS, 2026-11-08).
CVSS scores
| assigned by | version | score | vector |
|---|---|---|---|
| CNA | 3.1 | 7.0 | CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H |
Affected products
- Linux Linux
Classification
- Weakness
-
- CWE-667 Improper Locking
- Technology feeds
References
-
git.kernel.org
/stable/c/e890656accee4c26d932ea388eb8936a6e22184d
patch
-
git.kernel.org
/stable/c/6499c9c8ec437a369e7e221dad91f6122b50759d
patch
-
git.kernel.org
/stable/c/c554ddc87af4d4e4be42f8aed1baec9e1c7588e0
patch
-
git.kernel.org
/stable/c/3ca80e3012c8be85b4f8d0d20eac8d3b17ff257e
patch
-
git.kernel.org
/stable/c/041acda6d9f96006703466449c10c9a69590c8b9
patch
-
git.kernel.org
/stable/c/d309d3308de658d87c42d97e044c89a226327526
patch
-
git.kernel.org
/stable/c/bfbcce6a7b0552a390620d9b2c4d2bcb1825cbdc
patch
-
git.kernel.org
/stable/c/90c500e4fd83fa33c09bc7ee23b6d9cc487ac733
patch
Sources
- CVE List CVE-2026-46299
- NVD CVE-2026-46299
Fencer Vulns keeps one entry per vulnerability: the CVE id wins, then GHSA, and records that alias each other are merged, except that two CVEs always keep separate entries. The same data is available as JSON.