CVE-2026-64360

What it actually does

This Linux kernel flaw affects the HFS and HFS+ filesystem parsers. The vulnerable function can return before initializing an output buffer when invalid B-tree node offsets or zero-length corrected reads are encountered. Some callers then consume stack-allocated data as if it were valid, creating an uninitialized-memory read condition. The most likely technical consequence is exposure of unintended kernel memory values or unstable parser behavior when a crafted HFS/HFS+ filesystem is processed. Exploitation generally requires the kernel to mount or otherwise parse a malicious HFS/HFS+ volume, disk image, removable device, or file-backed filesystem.

Why it matters to the business

Systems that process untrusted storage media or disk images could leak sensitive kernel memory data or experience reliability issues when handling malformed HFS/HFS+ filesystems. The risk is currently low based on the very low EPSS score, absence from CISA KEV, no known ransomware association, and no reported public exploit maturity, but organizations with automated mounting, forensic intake, backup ingestion, file-conversion, or virtual-disk processing workflows should treat exposure more seriously because malformed filesystems may be processed without direct administrator review.

How an attack unfolds

An attacker creates a malformed HFS or HFS+ filesystem with B-tree metadata designed to trigger an early return in the kernel's hfs_bnode_read() path before the destination buffer is populated. The attacker then convinces a target system, service, analyst workstation, or automated processing pipeline to mount or inspect that filesystem, for example through removable media, an uploaded disk image, a virtual machine image, or a file-backed mount workflow. When the kernel parser reaches the malformed B-tree node data, helper functions may use uninitialized stack values. Depending on the surrounding code path and how returned values are surfaced, this can result in unintended kernel memory disclosure, anomalous behavior, or diagnostic reports on instrumented kernels. There is no evidence from the provided data that this vulnerability is currently used by named threat actors or ransomware campaigns.

How to fix it

Update to a Linux kernel build that includes the upstream fix which zero-initializes the buffer at the start of hfs_bnode_read(). Because no exact affected package list or fixed package versions were provided, use the security advisories from the relevant Linux distribution or appliance vendor to identify the corrected kernel package for each platform. Where immediate patching is not possible, reduce exposure by disabling or restricting HFS and HFS+ filesystem support if not required, preventing automatic mounting of removable media and disk images, blocking untrusted users from mounting filesystems, and processing untrusted disk images only in isolated, disposable sandbox environments. Kernel module blacklisting may be appropriate where HFS/HFS+ support is unnecessary, but validate impact first because some workflows may depend on reading legacy Apple-formatted media.

How to confirm the fix worked

Confirm remediation by verifying that each system is running a kernel package that includes the HFS/HFS+ hfs_bnode_read() zero-initialization fix from the applicable vendor. Review distribution changelogs, kernel source package patches, or vendor security errata for references to hfs_bnode_read, hfs/hfsplus buffer initialization, or CVE-2026-64360. Validate exposure reduction by checking whether HFS and HFS+ modules can be loaded, whether automount services mount removable filesystems automatically, and whether unprivileged users or automated services can mount user-supplied disk images. On test systems, a KMSAN-instrumented kernel should no longer report uninitialized-value warnings in hfs_bnode_read(), hfs_bnode_read_u16(), or hfs_bnode_read_u8() when processing malformed HFS/HFS+ test media.

Typical attack path

1. Prepare a crafted HFS or HFS+ filesystem image containing malformed B-tree node metadata that causes invalid offset or zero-length read handling.
2. Deliver the image through removable media, file upload, email attachment, shared archive, virtual disk, backup set, or another workflow that may cause filesystem parsing.
3. Trigger mounting or inspection of the crafted filesystem by the Linux kernel, either manually, through automount behavior, or through an automated ingestion pipeline.
4. Cause hfs_bnode_read() to return before initializing the caller-provided stack buffer.
5. Rely on callers consuming the uninitialized value, potentially exposing kernel memory-derived data or causing abnormal parser behavior.

How to detect it

To assess possible prior exploitation, review system, kernel, audit, and endpoint telemetry for evidence that untrusted HFS or HFS+ filesystems were mounted or parsed before the kernel was fixed. Useful log sources include journald, syslog, kern.log, dmesg captures, auditd mount syscall records, udisks/desktop automount logs, EDR device-control logs, removable-media events, and application logs from services that ingest disk images or virtual disks. Look for HFS/HFS+ mount attempts followed by kernel warnings, filesystem validation errors, KMSAN reports, crashes, service anomalies, or access to recently received disk image files. Because this issue is primarily an uninitialized-memory read, there may be no reliable persistent artifact after successful triggering; absence of logs does not prove non-exploitation. Focus investigation on systems that accepted removable media, mounted user-supplied images, or processed archives containing disk images around the publication and pre-remediation window.

• KMSAN: uninit-value in hfs_bnode_read
• KMSAN: uninit-value in hfs_bnode_read_u16
• KMSAN: uninit-value in hfs_bnode_read_u8
• hfs_bnode_read
• hfs_bnode_read_u16
• hfs_bnode_read_u8
• type hfs
• type hfsplus
• filesystem type 'hfs'
• filesystem type 'hfsplus'
• mount -t hfs
• mount -t hfsplus
• modprobe hfs
• modprobe hfsplus
• /lib/modules/*/kernel/fs/hfs/hfs.ko
• /lib/modules/*/kernel/fs/hfsplus/hfsplus.ko

What your security team should do

• Inventory Linux systems and workflows that mount or parse HFS/HFS+ filesystems, especially endpoints with removable-media automounting and servers that process uploaded disk, backup, forensic, or virtual-machine images.
• Prioritize kernel updates for systems that handle untrusted storage media or disk images, even though current exploitation likelihood is low.
• Disable or blacklist HFS/HFS+ support on systems where it is not operationally required, after confirming there is no business dependency.
• Disable automatic mounting of removable media and untrusted disk images; require controlled, sandboxed handling for filesystem inspection workflows.
• Restrict mount privileges and review use of user-space tools or services that invoke kernel mounts on behalf of non-privileged users.
• Monitor kernel and system logs for HFS/HFS+ mount activity, malformed filesystem errors, and KMSAN or kernel warnings involving hfs_bnode_read paths.
• Track Linux distribution advisories for exact fixed kernel package versions and ensure the fix is included in golden images, container hosts, appliances, and long-lived servers.