CVE-2026-64296

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.