CVE-2026-46169

What it actually does

This flaw is in the Linux kernel HFS+ filesystem driver. When the kernel reads a malformed HFS+ catalog record, it may accept an on-disk record that is shorter than the structure the kernel expects. That leaves part of the in-kernel structure uninitialized, and later HFS+ name-handling code can use those uninitialized bytes. The practical impact is local kernel memory misuse that can lead to a kernel warning, crash, or denial of service when a crafted or corrupted HFS+ filesystem is mounted. The supplied CVSS vector indicates local attack requirements, low complexity, low privileges, no user interaction, and high availability impact, with no expected confidentiality or integrity impact.

Why it matters to the business

Systems that mount HFS+ filesystems, including removable media, disk images, forensic images, or legacy Apple-formatted volumes, may be crashed by a malformed filesystem. This can interrupt workloads, cause host reboots, disrupt endpoint or server availability, and affect environments that process untrusted storage images. Exploitation is less urgent than remotely exploitable kernel flaws because it requires local access or a path to make the system mount a crafted HFS+ volume, EPSS is very low, it is not in CISA KEV, and no known exploit maturity is reported; however, shared systems, desktop fleets, forensic workstations, and automated media-processing pipelines should still treat it as a reliability and hardening issue.

How an attack unfolds

An attacker prepares a malformed HFS+ filesystem where a catalog record advertises or contains an invalid size for its record type, such as a thread record that is shorter than the kernel expects. The attacker then needs the target system to mount that filesystem, either by local access, removable media, a disk image handled by an automated process, or a workflow that mounts user-supplied storage images. During mount or catalog traversal, the Linux HFS+ driver reads only the short record but treats the operation as successful. Subsequent catalog lookup and string comparison paths copy or consume fields that were never initialized. This can trigger uninitialized-value behavior in kernel code and may result in a kernel warning, oops, panic, or other availability-impacting failure. There is no indication from the provided data that this vulnerability is being used in ransomware campaigns or by named threat actors.

How to fix it

Upgrade the Linux kernel to a version that includes the HFS+ fix introducing catalog-record size validation before HFS+ catalog records are consumed. Because no exact fixed package versions were provided, use the applicable Linux distribution security advisory or upstream stable kernel release notes for the commit or patch titled similarly to "hfsplus: fix uninit-value by validating catalog record size." Reboot into the updated kernel after installation. Where immediate patching is not possible, reduce exposure by preventing untrusted HFS+ filesystems from being mounted, disabling or blacklisting the hfsplus kernel module if HFS+ support is not required, restricting removable media automounting, and ensuring user-supplied disk images are inspected in isolated sandboxes rather than mounted on production systems.

How to confirm the fix worked

Confirm the running kernel, not just the installed package, has been updated to a release containing the HFS+ catalog record size validation fix. Verify through distribution package metadata, kernel changelogs, or vendor advisories. Check whether HFS+ support is loaded or available with commands such as reviewing loaded modules and supported filesystems. If HFS+ is not required, validate that attempts to load or mount HFS+ are blocked. In test environments only, regression validation can include attempting to mount a malformed HFS+ image that previously triggered KMSAN or kernel warnings and confirming the patched kernel rejects the malformed catalog record cleanly, typically with an I/O error rather than uninitialized-value warnings or a crash.

Typical attack path

1. Create or obtain a malformed HFS+ filesystem image with an invalidly short catalog record size.
2. Deliver the filesystem to a target context that will mount or inspect HFS+ volumes, such as removable media, a disk image, or an automated processing pipeline.
3. Cause the Linux system to mount the crafted HFS+ filesystem or otherwise traverse its catalog records.
4. Trigger HFS+ catalog lookup or name comparison code paths that read the malformed record.
5. Abuse the resulting uninitialized kernel data use to cause a kernel warning, crash, panic, or denial of service.

How to detect it

To determine whether this was already exploited or triggered, review kernel logs, system journals, crash dumps, and endpoint telemetry for HFS+ mount activity followed by kernel warnings, oopses, panics, or reboots. Relevant log sources include journald, syslog, dmesg output, kernel ring buffer captures, crash dump repositories, EDR telemetry for mount activity, removable media audit logs, udisks or desktop automount logs, and records from systems that process disk images. Look for stack traces or warnings referencing hfsplus_strcasecmp(), hfsplus_cat_build_key_uni(), hfsplus_find_cat(), hfs_brec_read(), case_fold(), KMSAN uninit-value reports, or messages about partial HFS+ btree record reads. Correlate those events with recent mounts of filesystems of type hfsplus, insertion of removable media, attachment of loop devices, or use of mount/udisks tools. Absence of these artifacts does not prove non-exploitation, especially if kernel logs rotated or the host crashed without persistent logging.

• hfsplus_strcasecmp
• hfsplus_cat_build_key_uni
• hfsplus_find_cat
• hfs_brec_read
• HFSPLUS_BREC_READ
• PARTIAL READ
• entrylength
• rec_len
• KMSAN: uninit-value
• uninit-value in hfsplus_strcasecmp
• case_fold
• filesystem type 'hfsplus'
• type hfsplus
• mount -t hfsplus
• hfsplus:
• kernel BUG
• kernel panic
• Oops:
• udisksd
• /lib/modules/*/kernel/fs/hfsplus/hfsplus.ko
• /proc/filesystems

What your security team should do

• Prioritize kernel updates on systems that mount removable media, user-supplied disk images, forensic images, or legacy HFS+ volumes.
• Disable or blacklist the hfsplus kernel module where HFS+ support is not operationally required.
• Disable automatic mounting of removable media and disk images on endpoints, kiosks, shared Linux workstations, and processing servers.
• Route untrusted filesystem images through isolated analysis sandboxes or disposable virtual machines rather than production hosts.
• Monitor kernel logs for HFS+ mount failures, KMSAN uninitialized-value reports, kernel oopses, and panics involving hfsplus functions.
• Review recent mount activity for unexpected HFS+ filesystems, especially around the time of unexplained host crashes or reboots.
• Track distribution advisories for exact fixed kernel package versions and ensure systems are rebooted into the remediated kernel.