PT-2026-64517 · Linux · Linux
CVE-2026-64296
·
Published
2026-07-25
·
Updated
2026-07-25
None
No severity ratings or metrics are available. When they are, we'll update the corresponding info on the page.
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. Found an issue in the description? Have something to add? Feel free to write us 👾
Related Identifiers
Affected Products
Linux