Threaticon
Toggle sidebar

You're viewing a limited, public preview. Log in for full access.

Log in User Guide
Log in Get started
Vulnerabilities CVE-2026-64296

CVE-2026-64296

None
Open
TLP:CLEAR

exfat: bound uniname advance in exfat_find_dir_entry()

AI Analysis

No AI analysis yet.

Description

In the Linux kernel, the following vulnerability has been resolved: exfat: bound uniname advance in exfat_find_dir_entry() In exfat_find_dir_entry(), each TYPE_EXTEND (file name) entry advances the output pointer by a fixed amount while the loop guard only tracks the accumulated name length: if (++order == 2) uniname = p_uniname->name; else uniname += EXFAT_FILE_NAME_LEN; len = exfat_extract_uni_name(ep, entry_uniname); name_len += len; unichar = *(uniname+len); *(uniname+len) = 0x0; uniname grows by EXFAT_FILE_NAME_LEN (15) per name entry, but name_len grows only by the actual extracted length, which is shorter when a name fragment contains an early NUL. The only guard is `name_len >= MAX_NAME_LENGTH`, so a crafted directory with many short name fragments lets uniname run far past the p_uniname->name[MAX_NAME_LENGTH + 3] buffer while name_len stays small, causing an out-of-bounds read and write at *(uniname+len). The sibling extractor exfat_get_uniname_from_ext_entry() already stops on a short fragment (the lockstep `len != EXFAT_FILE_NAME_LEN` guard added in commit d42334578eba ("exfat: check if filename entries exceeds max filename length")); exfat_find_dir_entry() never got the equivalent. Track the per-entry write offset as a count and reject a fragment once the offset, or the offset plus the extracted length, would exceed MAX_NAME_LENGTH, before forming the output pointer.

Details

EPSS Score
0.16%

6th percentile

Confidence
90%
Published
Jul 25, 2026
Last Modified
Jul 25, 2026
No notes yet. Click "Add Note" to create the first analysis note.
No opinions yet. Be the first to assess this intelligence.
Leaving Threaticon

This link opens an external site that isn't part of the platform.