CVE-2026-64296

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