CVE-2026-93095 in Linux
Summary
by MITRE • 09/18/2026
In the Linux kernel, the following vulnerability has been resolved:
hfsplus: validate thread record before delete key rebuild
hfsplus_delete_cat() is called with str == NULL when the last open reference to an unlinked HFS+ hardlink backing inode is closed. In that case, the function finds the catalog thread by CNID and rebuilds the catalog key from thread.nodeName.
That reconstruction path reads thread.nodeName.length directly from the catalog B-tree into fd.search_key and then copies length * 2 bytes into fd.search_key->cat.name.unicode. It does not first check that the found record is a thread record or that its size matches the thread name.
A corrupted image can therefore provide an oversized thread name length and make hfs_bnode_read() write past the catalog search-key allocation.
Read the CNID record through hfsplus_brec_read_cat(), which bounds the record read to sizeof(hfsplus_cat_entry) and verifies that a thread record's size exactly matches nodeName.length. Together, these checks ensure an accepted thread name fits HFSPLUS_MAX_STRLEN. Reject non-thread records before building the delete key from the validated thread name.
Share the thread-record-type helper between hfsplus_find_cat() and hfsplus_delete_cat().
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 09/18/2026
The vulnerability identified in the Linux kernel's HFS+ filesystem driver stems from a critical lack of input validation during the deletion process for catalog entries, specifically within the hfsplus_delete_cat function. This issue manifests when an unlinked hardlink backing inode is closed and its last open reference is released, triggering a call to hfsplus_delete_cat with a null string pointer. In this specific operational context, the kernel attempts to reconstruct the catalog key by locating the associated thread record using the Catalog Node ID (CNID). The core technical flaw lies in how this reconstruction path handles data retrieved from the HFS+ B-tree structure. Instead of performing rigorous validation before processing, the code directly reads the nodeName.length field from the raw catalog B-tree entry into a search buffer and subsequently copies length multiplied by two bytes into the unicode name field without verifying the integrity or type of the source record.
This absence of boundary checks creates a severe out-of-bounds write vulnerability that can be exploited through maliciously crafted HFS+ disk images. An attacker who controls the contents of an external drive formatted with HFS+ could embed a corrupted catalog entry where the thread name length field is set to an excessively large value. When the kernel processes this malformed record, it proceeds to copy data based on this untrusted length parameter into fd.search_key->cat.name.unicode. Since the destination buffer has a fixed size defined by system limits such as HFSPLUS_MAX_STRLEN, writing past its allocated boundary results in memory corruption. This type of flaw is classically categorized under CWE-120 Buffer Copy without Checking Size of Input and represents a significant risk for remote code execution or kernel panic depending on the specific memory layout at the time of exploitation.
The operational impact of this vulnerability extends beyond simple data corruption, as it compromises the stability and security of the host system running the Linux kernel. By exploiting this out-of-bounds write, an attacker could potentially overwrite adjacent kernel structures, leading to arbitrary code execution with root privileges or causing a denial of service through a kernel crash. The attack vector is particularly dangerous because it requires only physical access to mount a maliciously formatted volume, which falls under the Physical Access category in many threat models but can be facilitated via removable media attacks. In terms of ATT&CK framework mapping, this vulnerability aligns with techniques involving exploitation for privilege escalation or denial of service through memory corruption vulnerabilities on accessible storage devices.
The resolution implemented by the Linux kernel maintainers addresses these flaws by introducing strict validation logic before any key reconstruction occurs. The fix modifies hfsplus_delete_cat to utilize hfsplus_brec_read_cat, a helper function that inherently bounds the record read operation to sizeof(hfsplus_cat_entry). This ensures that only valid catalog entry structures are processed and prevents reading arbitrary amounts of data from the B-tree. Furthermore, the patch adds explicit verification that if the found record is indeed a thread record, its actual size must exactly match the nodeName.length field contained within it. These combined checks guarantee that any accepted thread name will fit within HFSPLUS_MAX_STRLEN, thereby eliminating the possibility of buffer overflow during the copy operation.
In addition to fixing the immediate memory safety issue, the patch improves code quality and maintainability by refactoring how record types are identified. The developers introduced a shared helper function for determining thread-record-type, which is now utilized by both hfsplus_find_cat and hfsplus_delete_cat. This consolidation reduces code duplication and ensures consistent validation logic across different parts of the filesystem driver that interact with catalog entries. By rejecting non-thread records before attempting to build the delete key from the validated thread name, the kernel enforces a defense-in-depth approach where data integrity is verified at multiple stages. This comprehensive fix not only resolves the immediate vulnerability but also strengthens the overall robustness of the HFS+ implementation against malformed or maliciously constructed filesystem images.