GHSA-6R4V-32R5-FPV2
Vulnerability from github – Published: 2026-09-17 18:31 – Updated: 2026-09-18 18:31In the Linux kernel, the following vulnerability has been resolved:
fs/ntfs3: reject out-of-range evcn in mi_enum_attr()
In mi_enum_attr(), the start/end VCN validation for non-resident attributes is:
if (svcn > evcn + 1) goto out;
When evcn is U64_MAX the "evcn + 1" expression wraps to 0 and any svcn passes the check. For evcn values close to U64_MAX (but not equal to it) the right-hand side is still a meaningless near-wrap upper bound, so a malformed on-disk attribute with svcn == 0 and evcn near U64_MAX can pass mi_enum_attr() unrejected.
VCN (virtual cluster number) is a cluster index, so any valid evcn is bounded by the volume's total cluster count, which ntfs3 holds in sbi->used.bitmap.nbits (set up in ntfs_init_from_boot() before any caller of mi_enum_attr() runs). Reject evcn values that fall outside this range.
However, an empty non-resident attribute (no allocated clusters) is legitimately encoded with svcn == 0 and evcn == -1 (U64_MAX), e.g. via attr->nres.evcn = cpu_to_le64((u64)vcn - 1) with vcn == 0. That sentinel must keep passing, so exclude evcn == U64_MAX from the range check. The existing "svcn > evcn + 1" test still tolerates the sentinel ("0 > 0" is false) and continues to require svcn == 0 for it, while the range check rejects every other out-of-range evcn and thereby also defuses the "evcn + 1" wraparound.
svcn does not need its own bound: once evcn < nbits, "svcn > evcn + 1" implies svcn <= nbits.
[almaz.alexandrovich@paragon-software.com: fixed evcn check]
{
"affected": [],
"aliases": [
"CVE-2026-90199"
],
"database_specific": {
"cwe_ids": [],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-09-17T17:17:14Z",
"severity": "HIGH"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nfs/ntfs3: reject out-of-range evcn in mi_enum_attr()\n\nIn mi_enum_attr(), the start/end VCN validation for non-resident\nattributes is:\n\n\tif (svcn \u003e evcn + 1) goto out;\n\nWhen evcn is U64_MAX the \"evcn + 1\" expression wraps to 0 and any svcn\npasses the check. For evcn values close to U64_MAX (but not equal to it)\nthe right-hand side is still a meaningless near-wrap upper bound, so a\nmalformed on-disk attribute with svcn == 0 and evcn near U64_MAX can pass\nmi_enum_attr() unrejected.\n\nVCN (virtual cluster number) is a cluster index, so any valid evcn is\nbounded by the volume\u0027s total cluster count, which ntfs3 holds in\nsbi-\u003eused.bitmap.nbits (set up in ntfs_init_from_boot() before any caller\nof mi_enum_attr() runs). Reject evcn values that fall outside this range.\n\nHowever, an empty non-resident attribute (no allocated clusters) is\nlegitimately encoded with svcn == 0 and evcn == -1 (U64_MAX), e.g. via\nattr-\u003enres.evcn = cpu_to_le64((u64)vcn - 1) with vcn == 0. That sentinel\nmust keep passing, so exclude evcn == U64_MAX from the range check. The\nexisting \"svcn \u003e evcn + 1\" test still tolerates the sentinel (\"0 \u003e 0\" is\nfalse) and continues to require svcn == 0 for it, while the range check\nrejects every other out-of-range evcn and thereby also defuses the\n\"evcn + 1\" wraparound.\n\nsvcn does not need its own bound: once evcn \u003c nbits, \"svcn \u003e evcn + 1\"\nimplies svcn \u003c= nbits.\n\n[almaz.alexandrovich@paragon-software.com: fixed evcn check]",
"id": "GHSA-6r4v-32r5-fpv2",
"modified": "2026-09-18T18:31:27Z",
"published": "2026-09-17T18:31:55Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-90199"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/0441e34ce098c19185a7b52c5b8b89a8a5b26888"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/20fd9f64c0050658f2031e6bd5d552c6f0c8f7e3"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/2b9a0e57bfd365e2096706b19ae34dce3b4a884b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/7ab69cef49ebdfee288287d62641b24ab1445ecc"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ce9a619c432b9a4044fee115c5483fbed946c131"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/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.