CVE-2026-43268

What it actually does

This vulnerability is a local denial-of-service issue in the Linux kernel HFS Plus filesystem driver. Certain HFS+ special inodes could be exposed with an inode mode that does not match one of the valid VFS file types expected by the kernel. After stricter VFS validation was introduced, attempts to open or operate on such malformed/special HFS+ inodes can trigger invalid-mode handling in kernel file-open paths, potentially causing kernel warnings, filesystem operation failures, or a system crash/panic depending on kernel configuration and runtime conditions. The impact is availability only; the published metadata does not indicate confidentiality or integrity compromise.

Why it matters to the business

An attacker with local access could disrupt Linux systems that mount or process HFS+ filesystems, such as systems handling disk images, removable media, forensic images, backup media, or cross-platform storage volumes. Successful exploitation may cause service interruption, host instability, or reboot requirements. The risk is lower than remotely exploitable kernel flaws because exploitation requires local access and an HFS+ filesystem exposure path, and current public metadata shows low EPSS, no known exploited status, no ransomware association, and no known mature exploit; however, kernel availability issues can still be operationally significant on shared servers, workstations, build systems, and media-processing infrastructure.

How an attack unfolds

An attacker first obtains local execution or the ability to influence a Linux host into mounting or accessing an HFS+ filesystem. They then provide or use an HFS+ volume containing special inode metadata that the vulnerable kernel represents with an invalid file mode. When a process attempts to open or traverse the affected inode, the VFS may reject the invalid mode or hit error-handling paths introduced by stricter inode type checks. On vulnerable kernels, this can result in a denial of service, such as a kernel warning escalation, filesystem access failure, hang, crash, or panic. Exploitation is most plausible where untrusted HFS+ images or removable media are mounted, inspected, indexed, backed up, or processed automatically.

How to fix it

Upgrade to a Linux kernel version that includes the upstream hfsplus fix that treats the affected HFS+ special inodes as regular files for VFS mode validation purposes. Where vendor kernels are used, apply the relevant distribution security update rather than relying only on upstream version numbers. If immediate patching is not possible, reduce exposure by disabling or restricting HFS+ filesystem mounting where it is not required, preventing untrusted users from mounting filesystems, disabling automount of removable media, avoiding automatic processing of untrusted HFS+ disk images, and isolating systems that must inspect untrusted filesystem images. Consider using sandboxed or disposable analysis environments for removable media and disk-image handling workflows.

How to confirm the fix worked

Confirm that the running kernel package includes the vendor fix for this hfsplus issue. Validate exposure by checking whether the hfsplus kernel module is present, loadable, or currently loaded, and whether HFS+ filesystems are mounted or automatically handled. On Linux systems, commands such as `uname -a`, distribution package-manager queries, `lsmod | grep hfsplus`, `modinfo hfsplus`, and `findmnt -t hfsplus,hfsplusplus` can help determine kernel version and HFS+ usage. After patching, reboot into the fixed kernel and verify the running kernel is the updated one, not merely installed on disk. If a safe regression test is available from the vendor or upstream kernel test suite, perform it in a non-production environment using HFS+ media that exercises special inode handling and confirm no kernel warnings, oopses, or panics occur.

Typical attack path

1. Gain local authenticated access to a Linux system, or gain the ability to supply an HFS+ disk image or removable HFS+ volume to a system that will mount or inspect it.
2. Prepare or obtain an HFS+ filesystem containing special inode metadata that triggers invalid inode mode handling in the vulnerable hfsplus driver.
3. Cause the vulnerable kernel to mount, traverse, index, scan, or otherwise access the crafted HFS+ filesystem.
4. Trigger an open or file operation on the affected special inode.
5. Induce kernel-level availability impact, potentially including filesystem operation failure, host instability, crash, panic, or forced reboot.

How to detect it

To assess prior exploitation, review kernel and system logs for signs of HFS+ filesystem access followed by VFS inode-mode errors, kernel warnings, oopses, panics, hangs, or unexpected reboots. Useful log sources include `dmesg`, journald (`journalctl -k`), `/var/log/kern.log`, `/var/log/messages`, `/var/log/syslog`, crash dump metadata, kdump/vmcore records, audit logs for mount activity, automount logs, removable-media service logs, and EDR telemetry showing disk-image mount or loop-device activity. Focus on timelines where HFS+ volumes were mounted, loop devices were attached, removable media was inserted, or disk images were scanned, then correlate with kernel instability. Look for users invoking `mount`, `udisksctl`, `losetup`, disk-image processing tools, backup tools, forensic tools, or file indexers shortly before a kernel panic or reboot. Absence of explicit hfsplus errors does not rule out exploitation, because a kernel crash may truncate logs; persistent crash dumps and out-of-band management event logs may be needed to confirm the sequence.

• hfsplus
• mount -t hfsplus
• mount -t hfsplusplus
• udisksctl mount
• losetup
• /dev/loop
• findmnt -t hfsplus
• findmnt -t hfsplusplus
• modprobe hfsplus
• hfsplus.ko
• VFS:
• invalid mode
• may_open
• kernel BUG
• kernel panic
• Oops:
• Call Trace:
• general protection fault
• unable to handle kernel NULL pointer dereference
• blocked for more than
• watchdog: BUG: soft lockup
• watchdog: BUG: hard LOCKUP

What your security team should do

• Prioritize patching Linux systems that mount or process HFS+ volumes, removable media, disk images, forensic images, backup media, or user-supplied storage content.
• Apply vendor-supplied kernel updates and reboot systems into the fixed kernel; track systems that have installed but not yet booted into the patched kernel.
• Restrict local users from mounting arbitrary filesystems unless required, and review use of user namespaces, FUSE workflows, automount services, and removable-media policies that could increase exposure.
• Disable or blacklist the hfsplus module on systems that do not need HFS+ support, after confirming this will not break business workflows.
• Ensure untrusted filesystem images are processed only in sandboxed, disposable, or isolated environments.
• Monitor kernel logs for hfsplus, VFS, invalid inode mode, oops, BUG, panic, or unexpected reboot events, especially on systems that handle removable media or disk images.
• Because this is not currently listed as known exploited and has low EPSS, treat it as a targeted hardening and availability risk rather than an emergency internet-facing exposure, unless HFS+ processing is part of a high-risk workflow.