Look up another CVE · open CVE-2026-90199 in the interactive tracker
CVE-2026-90199
fs/ntfs3: reject out-of-range evcn in mi_enum_attr()
Published 2026-09-17 (31 days ago) by the Linux kernel CNA. Subsystem fs/ntfs3. Debian urgency: not yet assigned.
What to do, per Debian release
Debian's own status for CVE-2026-90199 in every release this site tracks, and what each one means in practice. Every status below is the one the Debian Security Team publishes for this CVE. source
| Release | Status | Version | What this means |
|---|---|---|---|
| Debian 12bookworm | vulnerable | 6.1.190-1 | No fix published anywhere yet, neither in Debian nor upstream for the series bookworm tracks. Watch the Debian tracker page for this CVE. Advisories for bookworm have historically landed a median of 23 days after publication. |
| Debian 13trixie | fixedDSA-6528-1 · 2026-09-29 · text | 6.12.111-1 | Update the kernel and reboot. DSA-6528-1 shipped the fix on 2026-09-29, in 6.12.111-1. A running kernel keeps the old code until the machine restarts. |
| Debian 14forky | fixed | 7.2.6-1 | Update the kernel and reboot. Fixed in 7.2.6-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 7.2.6-1 | Update the kernel and reboot. Fixed in 7.2.6-1. A running kernel keeps the old code until the machine restarts. |
| Debian 12bookworm · linux-6.12 | fixedDLA-4817-1 · 2026-10-04 · text | 6.12.111-1~deb12u1 | Update the kernel and reboot. DLA-4817-1 shipped the fix on 2026-10-04, in 6.12.111-1~deb12u1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
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]
Where it lives
The fix touches these files. If the subsystem is one you do not use, the practical exposure is lower, though the package is still the vulnerable one.
fs/ntfs3/record.c
- What this is
- NTFS3 FILESYSTEMMAINTAINERS section matched on fs/ntfs3/ · ntfs3@lists.linux.dev · Supported
- Kernel module
- ntfs3
Check it on the machine
grep -w CONFIG_NTFS3_FS /boot/config-$(uname -r)Reads the booted kernel's own configuration, on the machine and nowhere else. =y is built in, =m is a module, and an is not set line means the code is not there.
lsmod | grep -w ntfs3Prints a line if that module is loaded right now, and nothing if it is not. One that is not loaded can still be loaded later by anything that needs it.
Show whether Debian builds this, per release
Debian does not build this code in 3 releases. It does build it in 2 releases, so the answer depends on which release the machine runs.
- bookwormn
- trixiem
- forky, sidn
- bookworm · linux-6.12m
- n
- not enabled on any flavour - this release does not build the code
- m
- a loadable module on every flavour - check lsmod, can be blacklisted
- Build switch
- CONFIG_NTFS3_FS
From the configuration Debian publishes for every kernel flavour it builds. It covers only the architectures Debian ships a linux-config package for, and nothing about a kernel you built yourself. Debian's own status above stays authoritative about the source package.MAINTAINERS kbuild Makefiles Debian linux-config packages
Signals
- Published
- 2026-09-17 (31 days ago)source
- CVSS
- 7.8 high
CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:Hsource recompute it - Attack vector
- local (AV:L)source
- EPSS
- 0.17%, higher than 6.4% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- not yet assignedsource
- Subsystem
- fs/ntfs3
Upstream fixes
The versions the CNA records as introducing and fixing this, and the commit for each. source
| Introduced | Fixed in | Commit |
|---|---|---|
| 6.6 | 6.6.157 | 0441e34ce098 |
| 6.6 | 6.12.110 | 7ab69cef49eb |
| 6.6 | 6.18.52 | ce9a619c432b |
| 6.6 | 7.2.6 | 2b9a0e57bfd3 |
| 6.6 | 7.3 | 20fd9f64c005 |
| 5.15.209 | 0 | 0 |
| 6.1.115 | 0 | 0 |
| 6.5.11 | 0 | 0 |
Debian advisories
| Advisory | Date | Shipped to | Debian |
|---|---|---|---|
| DLA-4817-1 | 2026-10-04 | bookworm 6.12.111-1~deb12u1 | tracker |
| DSA-6528-1 | 2026-09-29 | trixie 6.12.111-1 | tracker |
Why the CNA scored it this way
Quoted from the kernel CNA's own scoring file, word for word. A highlighted metric carries the most severe value CVSS v3.1 defines for it, which is what pushes the score up. source
- AV:LAttack vector, local
- The malformed field is attr->nres.evcn (with svcn) in a non-resident MFT attribute on the block device. It is parsed by mount(2) → ntfs_fill_super() → ntfs_iget5() → ntfs_read_mft() → ni_enum_attr_ex() → mi_enum_attr(); no network protocol carries those VCN fields.
- AC:LAttack complexity, low
- The attacker sets on-disk evcn ≥ sbi->used.bitmap.nbits or near U64_MAX with svcn==0 so mi_enum_attr()'s u64 test `svcn > evcn + 1` never fails (evcn+1 wraps only at U64_MAX). A single sparse mapping pair of length evcn+1 then makes run_unpack() succeed; there is no race.
- PR:NPrivileges required, none
- Crafting the NTFS image requires no account on the target. ntfs_fs_type has no FS_USERNS_MOUNT, so the CAP_SYS_ADMIN mount is the victim's action and is counted as UI:R rather than attacker privilege.
- UI:RUser interaction, required
- A victim must mount the attacker-supplied NTFS volume so ntfs_fill_super()/ntfs_read_mft() will run mi_enum_attr() on the crafted evcn; that mount is the required user action.
- S:UScope, unchanged
- Corruption stays in the host kernel's ntfs3 runs_tree and MFT record buffers; no VM, IOMMU, or sandbox boundary is crossed.
- C:HConfidentiality impact, high
- Accepted evcn near U32_MAX is passed to run_unpack_ex() and installed as a sparse run of length ~U32_MAX. A later write hits run_add_entry(), which splits that run with wrapping CLST adds (r->vcn+r->len, tail_len=r->len-Tovcn), so lookups return wrong LCNs and can read past the kvmalloc'd runs array.
- I:HIntegrity impact, high
- The same wrapping split does `r->len += len - ((r->vcn + r->len) - vcn)` and run_consolidate() joins on wrapped end points; mi_pack_runs() then writes the corrupted mapping pairs into the kmalloc'd MFT record — a kernel-heap write of attacker-influenced run metadata.
- A:HAvailability impact, high
- Walking off the runs array on the wrapped split, or submitting an iomap bio from a wrapped LCN in ntfs_iomap_begin() after attr_data_get_block(), oopses the kernel; attr_set_size_ex() also takes _ntfs_bad_inode() on the inconsistent vcn/evcn state.