CVE-2026-90199fs/ntfs3: reject out-of-range evcn in mi_enum_attr()
Updated under an hour ago ()
Does this affect you?
It affects Linux. Add what you run to find out whether that includes you.
No exploitation reported and no EPSS estimate yet.
Do this next
Free account, 1 product
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 check]
- CVSS
- 7.8 HIGH (v3.1, CNA)CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H
- Weakness (CWE)
- Not given
- Known exploited
- Not in CISA's KEV catalog
- EPSS (exploitation in the next 30 days)
- Not loaded for this CVE
- Assigned by
- Linux
- NVD analysis
- Received
- Record last updated
- Sep 18, 2026
- First seen by InfoSec Signals
- Oct 9, 2026
Affected products
Linux Linux linux:linux (from the name) | from 013ff63b649475f0ee134e2c8d0c8e65284ede50 before 0441e34ce098c19185a7b52c5b8b89a8a5b26888; 013ff63b649475f0ee134e2c8d0c8e65284ede50 builds before 7ab69cef49ebdfee288287d62641b24ab1445ecc; from 013ff63b649475f0ee134e2c8d0c8e65284ede50 before ce9a619c432b9a4044fee115c5483fbed946c131; 013ff63b649475f0ee134e2c8d0c8e65284ede50 builds before 2b9a0e57bfd365e2096706b19ae34dce3b4a884b; from 013ff63b649475f0ee134e2c8d0c8e65284ede50 before 20fd9f64c0050658f2031e6bd5d552c6f0c8f7e3; a7accf181a4709a6e380360372150cc4a1b6b89a; 3dfd727873c3e8da74a2e3907120ff052c5f0bcc; 1d7dd485108d4f633b543c9c14071cc325b68ae5; and 3 more ranges | CNA record |
References
- https://git.kernel.org/stable/c/0441e34ce098c19185a7b52c5b8b89a8a5b26888
- https://git.kernel.org/stable/c/7ab69cef49ebdfee288287d62641b24ab1445ecc
- https://git.kernel.org/stable/c/ce9a619c432b9a4044fee115c5483fbed946c131
- https://git.kernel.org/stable/c/2b9a0e57bfd365e2096706b19ae34dce3b4a884b
- https://git.kernel.org/stable/c/20fd9f64c0050658f2031e6bd5d552c6f0c8f7e3
The CVE record on cve.org NVD's entry
The CVE record is authoritative. Products marked “from the name” were identified from the CNA's free-text names, not a CPE, and are matched less certainly. This product uses the NVD API but is not endorsed or certified by the NVD.