Cloudanix VulnDB

CVE-2026-93095

High · 7.8

CVSS

7.8

EPSS

0.2%

Published

Sep 17, 2026

CISA due date

—

Cloudanix analysis

Next patch cycle SSVC: Track

A bug in the Linux kernel's code for handling certain older Mac-style storage formats can let someone with local access crash the computer or take control by feeding it a specially made disk image.

Exploitation
Local Privilege
Attacker needs
Low Privilege
Complexity
Moderate
Impact
Full Compromise
Component
OS kernel
Class
Buffer Overflow
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

Out-of-bounds write in hfsplus_delete_cat() when a NULL string parameter triggers reconstruction of a catalog key from an unvalidated thread record; the function reads nodeName.length directly and copies length*2 bytes without checking record type or size, allowing an oversized value from a corrupted HFS+ image to overflow the search-key allocation via hfs_bnode_read().

Why it matters to the business

Local attackers on Linux systems that mount HFS+ volumes can trigger kernel memory corruption, enabling privilege escalation or denial of service; the issue affects any environment processing untrusted HFS+ images or hardlink operations.

How an attack unfolds

An attacker supplies a malicious HFS+ filesystem containing a catalog thread record with an inflated nodeName.length. When the last open reference to an unlinked hardlink backing inode is closed, hfsplus_delete_cat() is called with str==NULL, causing it to locate the thread by CNID, read the oversized length, and perform an unchecked copy that writes past the allocated buffer.

How to fix it

Apply the upstream kernel commit that replaces direct thread reads with hfsplus_brec_read_cat() (which bounds the read to sizeof(hfsplus_cat_entry) and verifies thread record size against nodeName.length) and shares the thread-record-type helper; rebuild and deploy the patched kernel across all affected systems.

How to confirm the fix worked

Confirm the presence of the bounds-checked hfsplus_brec_read_cat() call and the thread-record-type validation inside hfsplus_delete_cat(); attempt to reproduce the overflow using a test image with an oversized thread name and verify the operation is now rejected before any copy occurs.

Typical attack path

  1. Mount a crafted HFS+ image containing a corrupted catalog thread record
  2. Perform file operations that create and then unlink a hardlink on the volume
  3. Close the final reference to the unlinked backing inode to invoke the vulnerable delete path
  4. Trigger the reconstruction logic that performs the unbounded copy

How to detect it

Review kernel logs and dmesg output for hfsplus-related oops, panics, or buffer-overrun warnings during filesystem unmount or hardlink close events; correlate with mount activity of HFS+ volumes from untrusted sources.

What your security team should do

  • Prioritize kernel upgrades containing the hfsplus validation fix on all systems that may mount HFS+ volumes
  • Disable or restrict auto-mounting of removable media and untrusted HFS+ images until patches are applied
  • Add kernel module logging for hfsplus to detect unusual catalog operations during incident response

The record

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().

Affected packages

Ecosystem Package Introduced Fixed