CVE-2026-43228

What it actually does

This vulnerability is a local denial-of-service flaw in the Linux kernel HFS filesystem implementation. A malformed or corrupted HFS volume can cause kernel execution to hit a BUG_ON assertion during catalog node ID, folder count, or file count validation. Because BUG_ON is a fatal kernel assertion, mounting or otherwise processing the crafted HFS filesystem can trigger a kernel oops or panic, resulting in system crash or loss of availability. The fix replaces the fatal assertion with normal error handling so corrupted metadata is rejected instead of crashing the kernel.

Why it matters to the business

Systems that allow users or automated workflows to mount untrusted HFS-formatted media or disk images could be crashed by a local user or by processing a malicious file/device, causing service interruption, failed jobs, or host reboot. The practical internet-wide risk is low because exploitation requires local access and there is no known public exploit, KEV listing, or ransomware association, but shared Linux workstations, forensic/image-processing systems, removable-media handling systems, and virtualization/container hosts that expose filesystem mounting paths should treat it as an availability risk.

How an attack unfolds

An attacker first obtains local execution privileges or access to a workflow that can cause the target system to mount or inspect an HFS filesystem. They then supply a deliberately corrupted HFS volume, removable device, or disk image with metadata values that trigger overflow/count consistency checks in the kernel HFS driver. When the vulnerable kernel parses the HFS master directory block and related superblock information, it reaches a BUG_ON condition instead of returning an error. The kernel then crashes or panics, causing denial of service until the host is rebooted or otherwise recovered. Exploitation does not provide code execution or data disclosure based on the published description; the primary outcome is availability loss.

How to fix it

Upgrade the Linux kernel to a vendor release that includes the HFS fix replacing the BUG_ON checks with recoverable error handling. Because no exact fixed package versions were provided, use distribution advisories for the affected kernel branch and confirm that the patch for the HFS CNID/folder/file count BUG_ON handling is included. Where immediate patching is not possible, reduce exposure by preventing untrusted users from mounting filesystems, disabling or blacklisting the HFS filesystem module if not required, restricting access to loop-device mounting, avoiding automatic mounting of removable media, and processing untrusted disk images only inside disposable sandboxed environments.

How to confirm the fix worked

Confirm the running kernel package is at or above the fixed version supplied by the relevant Linux distribution or kernel vendor. Validate that HFS support is not available where it is not needed by checking whether the hfs module is loaded or loadable, and verify mount policies prevent unprivileged users from mounting arbitrary HFS images. For patched systems, testing with malformed HFS images should result in a clean mount failure or kernel error message rather than a kernel oops, BUG, panic, or host reboot. Review kernel change logs or source patches for the replacement of HFS BUG_ON count checks with error returns.

Typical attack path

1. Gain local user access or access to a service/workflow that mounts or analyzes user-supplied filesystems.
2. Create or obtain a malformed HFS filesystem image or removable-media payload with corrupted count/CNID metadata.
3. Cause the vulnerable Linux kernel to mount or parse the crafted HFS volume.
4. Trigger the HFS driver BUG_ON assertion during filesystem metadata validation.
5. Crash the kernel or trigger a kernel oops/panic, causing denial of service.

How to detect it

Look for evidence that a local user, automount service, forensic tool, or image-processing workflow attempted to mount or inspect an HFS filesystem shortly before a kernel crash, reboot, oops, or panic. Primary log sources include kernel logs, system journal entries, syslog, auditd records for mount and losetup activity, endpoint telemetry showing mount helpers, and crash dump infrastructure such as kdump, vmcore, or kernel oops collectors. Useful artifacts include HFS-related kernel messages, mount commands specifying HFS, loop-device setup shortly before the crash, removable-device insertion events, and abrupt reboot records. Because the vulnerability causes denial of service rather than durable compromise, there may be no persistent file, process, registry, or network IOC; correlation of HFS mount activity with kernel BUG/oops/panic events is the strongest signal.

• kernel BUG at fs/hfs/
• BUG: unable to handle kernel
• Kernel panic - not syncing
• Oops:
• hfs:
• mount -t hfs
• type=hfs
• /sbin/mount.hfs
• losetup
• VFS: Can't find a HFS filesystem

What your security team should do

• Prioritize patching Linux systems that allow removable media, loop-mounted disk images, forensic processing, virtualization image handling, or user-driven filesystem mounting.
• If HFS is not operationally required, disable or blacklist the hfs kernel module and verify it cannot be automatically loaded.
• Restrict mount privileges, loop-device access, and automount behavior for untrusted users and uploaded disk images.
• Monitor kernel logs for HFS-related BUG, oops, or panic events, especially following mount attempts or removable-media activity.
• Treat unexpected host crashes associated with HFS mounting as potential exploitation attempts and preserve kernel logs, audit logs, and the triggering image/device for analysis.
• Track distribution advisories because exact fixed versions vary by kernel branch and vendor packaging.
• Do not give this vulnerability emergency internet-exposed priority based solely on EPSS; it has a low EPSS score, no known exploit maturity, and is not in CISA KEV, but it remains important for local availability-sensitive systems.