fs/ntfs3: reject out-of-range evcn in mi_enum_attr()
In 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 c
- Products
- Kernel
- Affected versions
- Not specified
- Fixed versions
- 6.12.110, 6.18.52, 6.6.157, 7.2.6
- CVEs
- CVE-2026-90199
- Confirmed fixed CVEs
- Not specified
- Updated in this feed
- 6 Nov 2026, 01:38 UTC · Revision 1
Source evidence
fs/ntfs3: reject out-of-range evcn in mi_enum_attr()
core-osv · Original sourcePublished 17 Sept 2026, 16:07 UTC
In 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 c
osv:CVE-2026-90199
Kernel
Fixed versions: 6.6.157, 6.12.110, 6.18.52, 7.2.6
Complete source record
{
"id": "43c9339b3884ea76675cc16055cdbd7dabb12a7d0318d14fda1cde2835b72104",
"url": "https://osv.dev/vulnerability/CVE-2026-90199",
"method": "structured",
"payload": {
"kind": "advisory",
"title": "fs/ntfs3: reject out-of-range evcn in mi_enum_attr()",
"summary": "In 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 c",
"evidence": "osv:CVE-2026-90199",
"products": [
{
"name": {
"value": "Kernel",
"evidence": "/affected/1/package/name"
},
"prerequisites": [],
"fixed_versions": [
{
"value": "6.6.157",
"evidence": "/affected/1/ranges"
},
{
"value": "6.12.110",
"evidence": "/affected/1/ranges"
},
{
"value": "6.18.52",
"evidence": "/affected/1/ranges"
},
{
"value": "7.2.6",
"evidence": "/affected/1/ranges"
}
],
"affected_versions": []
}
],
"severity": "high",
"structured": {
"id": "CVE-2026-90199",
"aliases": [
"CVE-2026-90199"
],
"metrics": [
{
"type": "CVSS_V3",
"score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H"
}
],
"affected": [
{
"ranges": [
{
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"type": "GIT",
"events": [
{
"introduced": "013ff63b649475f0ee134e2c8d0c8e65284ede50"
},
{
"fixed": "0441e34ce098c19185a7b52c5b8b89a8a5b26888"
},
{
"fixed": "7ab69cef49ebdfee288287d62641b24ab1445ecc"
},
{
"fixed": "ce9a619c432b9a4044fee115c5483fbed946c131"
},
{
"fixed": "2b9a0e57bfd365e2096706b19ae34dce3b4a884b"
},
{
"fixed": "20fd9f64c0050658f2031e6bd5d552c6f0c8f7e3"
}
]
},
{
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"type": "GIT",
"events": [
{
"introduced": "5.15.209"
},
{
"fixed": "5.16"
}
]
},
{
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"type": "GIT",
"events": [
{
"introduced": "6.1.115"
},
{
"fixed": "6.2"
}
]
},
{
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"type": "GIT",
"events": [
{
"introduced": "6.5.11"
},
{
"fixed": "6.6"
}
]
},
{
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"type": "GIT",
"events": [
{
"introduced": "a7accf181a4709a6e380360372150cc4a1b6b89a"
}
]
},
{
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"type": "GIT",
"events": [
{
"introduced": "3dfd727873c3e8da74a2e3907120ff052c5f0bcc"
}
]
},
{
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"type": "GIT",
"events": [
{
"introduced": "1d7dd485108d4f633b543c9c14071cc325b68ae5"
}
]
}
],
"versions": [
"v5.15.223",
"v5.15.222",
"v5.15.221",
"v5.15.220",
"v5.15.219",
"v5.15.218",
"v5.15.217",
"v5.15.216",
"v5.15.215",
"v5.15.214",
"v5.15.213",
"v5.15.212",
"v5.15.211",
"v5.15.210",
"v5.15.209",
"v6.1.190",
"v6.1.189",
"v6.1.188",
"v6.1.187",
"v6.1.186",
"v6.1.185",
"v6.1.184",
"v6.1.183",
"v6.1.182",
"v6.1.181",
"v6.1.180",
"v6.1.179",
"v6.1.178",
"v6.1.177",
"v6.1.176",
"v6.1.175",
"v6.1.174",
"v6.1.173",
"v6.1.172",
"v6.1.171",
"v6.1.170",
"v6.1.169",
"v6.1.168",
"v6.1.167",
"v6.1.166",
"v6.1.165",
"v6.1.164",
"v6.1.163",
"v6.1.162",
"v6.1.161",
"v6.1.160",
"v6.1.159",
"v6.1.158",
"v6.1.157",
"v6.1.156",
"v6.1.155",
"v6.1.154",
"v6.1.153",
"v6.1.152",
"v6.1.151",
"v6.1.150",
"v6.1.149",
"v6.1.148",
"v6.1.147",
"v6.1.146",
"v6.1.145",
"v6.1.144",
"v6.1.143",
"v6.1.142",
"v6.1.141",
"v6.1.140",
"v6.1.139",
"v6.1.138",
"v6.1.137",
"v6.1.136",
"v6.1.135",
"v6.1.134",
"v6.1.133",
"v6.1.132",
"v6.1.131",
"v6.1.130",
"v6.1.129",
"v6.1.128",
"v6.1.127",
"v6.1.126",
"v6.1.125",
"v6.1.124",
"v6.1.123",
"v6.1.122",
"v6.1.121",
"v6.1.120",
"v6.1.119",
"v6.1.118",
"v6.1.117",
"v6.1.116",
"v6.1.115",
"v6.5.13",
"v6.5.12",
"v6.5.11"
],
"database_specific": {
"source": "https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2026-90199.json"
}
},
{
"ranges": [
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "6.6.0"
},
{
"fixed": "6.6.157"
}
]
},
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "6.7.0"
},
{
"fixed": "6.12.110"
}
]
},
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "6.13.0"
},
{
"fixed": "6.18.52"
}
]
},
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "6.19.0"
},
{
"fixed": "7.2.6"
}
]
}
],
"package": {
"name": "Kernel",
"ecosystem": "Linux"
},
"database_specific": {
"source": "https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2026-90199.json"
}
}
],
"modified": "2026-10-28T02:30:45.812249905Z",
"provider": "osv",
"references": [
"https://git.kernel.org/stable/c/0441e34ce098c19185a7b52c5b8b89a8a5b26888",
"https://git.kernel.org/stable/c/20fd9f64c0050658f2031e6bd5d552c6f0c8f7e3",
"https://git.kernel.org/stable/c/2b9a0e57bfd365e2096706b19ae34dce3b4a884b",
"https://git.kernel.org/stable/c/7ab69cef49ebdfee288287d62641b24ab1445ecc",
"https://git.kernel.org/stable/c/ce9a619c432b9a4044fee115c5483fbed946c131",
"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/90xxx/CVE-2026-90199.json",
"https://nvd.nist.gov/vuln/detail/CVE-2026-90199",
"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git"
],
"provider_metadata": {
"cna_assigner": "Linux",
"osv_generated_from": "https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/90xxx/CVE-2026-90199.json"
}
},
"related_cves": [
{
"value": "CVE-2026-90199",
"evidence": "/id"
}
],
"security_relevant": true,
"severity_evidence": "/severity/0/score"
},
"source_id": "core-osv",
"document_id": 513937,
"published_at": "2026-09-17T16:07:17.55+00:00"
}