CVE-2026-64361

What it actually does

This is a local Linux kernel memory-safety flaw in the HFS/HFS+ filesystem code. A bounds check in check_and_correct_requested_length() performs off + len using 32-bit unsigned arithmetic; if len is extremely large because of an earlier underflow, the addition can wrap to a small value and incorrectly pass validation. The kernel may then execute a memmove() using an invalid length and access memory far beyond the intended filesystem node buffer. Depending on kernel build, memory layout, and trigger path, impact can include kernel crash, memory corruption, information disclosure, or potential local privilege escalation.

Why it matters to the business

Systems that allow users, services, desktop automounters, removable media workflows, containers, or backup/indexing tools to process untrusted HFS or HFS+ filesystem images could be crashed or potentially compromised at the kernel level. Successful exploitation can interrupt service availability and may let a local attacker gain elevated control over the host. The issue is not currently listed in CISA KEV, is not known to be used in ransomware campaigns, has very low EPSS, and has no reported mature public exploit, but it affects kernel code and should still be remediated through normal kernel patch cycles, with higher urgency on multi-user Linux systems or endpoints that handle untrusted disk images.

How an attack unfolds

An attacker first obtains local execution or otherwise causes a vulnerable Linux system to parse a malicious HFS/HFS+ filesystem. They prepare a crafted filesystem image with metadata values that cause an arithmetic underflow in an HFS B-tree record removal path, producing a very large length value. When the vulnerable kernel validates the requested operation, the 32-bit off + len calculation wraps around and appears to be within the node size. The invalid check allows execution to continue into a memmove() that reads or manipulates memory far beyond the node buffer. In the simplest case this causes a kernel oops or panic, denying service; with additional exploitation work, the memory corruption may be shaped into disclosure or privilege escalation.

How to fix it

Upgrade the Linux kernel to a vendor-supported release that contains the fix for the HFS/HFS+ check_and_correct_requested_length() integer overflow. No exact fixed package versions were provided in the input, so use the relevant distribution advisory and kernel changelog to identify the patched kernel, then reboot into it. If HFS/HFS+ support is not required, reduce exposure by disabling or blocking the hfs and hfsplus kernel modules, for example with modprobe policy such as install hfs /bin/false and install hfsplus /bin/false, plus blacklist entries where appropriate, followed by initramfs regeneration if those modules may be included there. Restrict untrusted filesystem mounting, disable desktop/server automount of removable media where unnecessary, limit CAP_SYS_ADMIN and privileged containers, and prevent users or services from processing untrusted HFS/HFS+ images on vulnerable hosts.

How to confirm the fix worked

Confirm the running kernel, not just the installed package, is a patched vendor build that includes the u64 widening fix in the HFS/HFS+ length check. Verify after reboot with uname -a and the distribution package manager. Check whether HFS/HFS+ support is present or loaded using lsmod, modinfo hfs, modinfo hfsplus, /proc/filesystems, and kernel configuration entries such as CONFIG_HFS_FS and CONFIG_HFSPLUS_FS. If mitigating by disabling modules, verify that modprobe hfs and modprobe hfsplus fail as intended and that HFS/HFS+ filesystems cannot be mounted. In controlled non-production testing only, validate that malformed HFS/HFS+ images that previously triggered kernel faults no longer cause oops, panic, or HFS/HFS+ stack traces.

Typical attack path

1. Gain local access to a Linux system, access to a workload that mounts/parses disk images, or a path to introduce removable/untrusted media.
2. Create or obtain a malformed HFS/HFS+ filesystem image with crafted B-tree metadata that triggers the vulnerable length calculation.
3. Cause the vulnerable kernel to mount, inspect, repair, index, or otherwise process the crafted filesystem.
4. Trigger the hfs_brec_remove() path so an underflowed length reaches check_and_correct_requested_length().
5. Exploit the 32-bit integer wraparound so the bounds check incorrectly succeeds.
6. Leverage the resulting out-of-bounds memmove() for kernel crash, memory corruption, possible information disclosure, or possible local privilege escalation.

How to detect it

Review kernel logs and system journals for HFS/HFS+ mount activity followed by kernel oops, panic, page fault, general protection fault, slab corruption, or stack traces referencing HFS/HFS+ B-tree functions. Useful log sources include dmesg, journalctl -k, /var/log/kern.log, /var/log/messages, auditd logs for mount or loop-device activity, EDR telemetry for mount/losetup invocations, and container runtime logs for privileged containers or host filesystem mount attempts. Look for suspicious mounting of .dmg, .iso, raw disk images, loop devices, removable media, or filesystems of type hfs or hfsplus shortly before a kernel fault. Because no public exploitation campaign or stable exploit is known from the provided data, detection should focus on crash artifacts, anomalous HFS/HFS+ parsing activity, and local users or processes introducing untrusted filesystem images.

• check_and_correct_requested_length
• hfs_brec_remove
• hfsplus_brec_remove
• hfs_bnode_read
• hfs_bnode_write
• hfs:
• hfsplus:
• type hfs
• type hfsplus
• mount -t hfs
• mount -t hfsplus
• modprobe hfs
• modprobe hfsplus
• losetup
• BUG: unable to handle page fault
• general protection fault
• kernel BUG
• Oops:
• Kernel panic
• memmove

What your security team should do

• Prioritize patching multi-user Linux servers, developer workstations, VDI hosts, container hosts, forensic/media-processing systems, and endpoints that handle removable media or disk images.
• Inventory systems with HFS/HFS+ support enabled or loaded, including kernels with hfs or hfsplus modules available.
• Apply the vendor kernel update that contains the fix and reboot to activate the patched kernel.
• Where HFS/HFS+ is not business-required, disable the hfs and hfsplus modules as a defense-in-depth control.
• Restrict untrusted filesystem mounting by limiting privileged containers, CAP_SYS_ADMIN, loop-device access, desktop automount, and removable-media workflows.
• Monitor kernel logs for crashes or stack traces involving hfs, hfsplus, hfs_brec_remove, check_and_correct_requested_length, or memmove following filesystem mount activity.
• Treat unexplained kernel crashes during HFS/HFS+ mount or parsing as potentially malicious until reviewed.