GHSA-6F82-HFHW-X2GC
Vulnerability from github – Published: 2026-07-25 12:31 – Updated: 2026-07-27 06:30In 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.
{
"affected": [],
"aliases": [
"CVE-2026-64296"
],
"database_specific": {
"cwe_ids": [],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-07-25T10:17:10Z",
"severity": "HIGH"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nexfat: bound uniname advance in exfat_find_dir_entry()\n\nIn exfat_find_dir_entry(), each TYPE_EXTEND (file name) entry advances the\noutput pointer by a fixed amount while the loop guard only tracks the\naccumulated name length:\n\n\tif (++order == 2)\n\t\tuniname = p_uniname-\u003ename;\n\telse\n\t\tuniname += EXFAT_FILE_NAME_LEN;\n\tlen = exfat_extract_uni_name(ep, entry_uniname);\n\tname_len += len;\n\tunichar = *(uniname+len);\n\t*(uniname+len) = 0x0;\n\nuniname grows by EXFAT_FILE_NAME_LEN (15) per name entry, but name_len\ngrows only by the actual extracted length, which is shorter when a name\nfragment contains an early NUL. The only guard is\n`name_len \u003e= MAX_NAME_LENGTH`, so a crafted directory with many short\nname fragments lets uniname run far past the\np_uniname-\u003ename[MAX_NAME_LENGTH + 3] buffer while name_len stays small,\ncausing an out-of-bounds read and write at *(uniname+len).\n\nThe sibling extractor exfat_get_uniname_from_ext_entry() already stops\non a short fragment (the lockstep `len != EXFAT_FILE_NAME_LEN` guard\nadded in commit d42334578eba (\"exfat: check if filename entries exceeds\nmax filename length\")); exfat_find_dir_entry() never got the\nequivalent. Track the per-entry write offset as a count and reject a\nfragment once the offset, or the offset plus the extracted length, would\nexceed MAX_NAME_LENGTH, before forming the output pointer.",
"id": "GHSA-6f82-hfhw-x2gc",
"modified": "2026-07-27T06:30:31Z",
"published": "2026-07-25T12:31:30Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-64296"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/33c0b96d7e1672be1de0053786637ea46fb81507"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3a1230e7b043c62737b05a3e9275ca83a43ad20a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/727bf7783a2936ffd55c628dddfd69343e511dcf"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/72a2589d82eb001c94b74bcfe6f9a599bd9bef60"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c8e041c68c0bbb73aa62371ee63947bb6949d8b2"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ce4736c1e6c4cfbf1ac409a8c328a0b69546c9a0"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/cf85180b8a015029ee147694eaf4e0b3537e9432"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/fae76a94b35ee8c0e2eb6f64caca01d75c6d34e4"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.