CVE-2026-72211: Linux kernel · ntfs: grow index root value before reparent header update
Affects Linux kernelSource GCVE Database
Not known to be exploited · CVSS 9.8 Critical.
Data as of 26 Oct 2026, 13:47 UTC
- EPSS
- 0.5% chance of exploitation in 30 days – higher than 45% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:HExploitation evidence
Disclosed: evidence found.
CVE published 17 Aug 2026
Detectable: no evidence on record.
No public nuclei template indexed
Weaponised: no evidence on record.
No public exploit code indexed in Metasploit or Exploit-DB
Exploited in the wildExploited: no evidence on record.
Not in CISA KEV and no source reports exploitation
Observed by OffSeq MirageSeen by Mirage: no evidence on record.
No attack traffic recorded by OffSeq Mirage sensors
A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 26 Oct 2026.
What to do
AI-suggested
The vulnerability description indicates that a fix has been implemented in the Linux kernel source code to reorder the resizing and header update operations. Users should monitor official Linux kernel advisories and update to a fixed kernel version once available.
Description
In the Linux kernel, the following vulnerability has been resolved: ntfs: grow index root value before reparent header update ntfs_ir_reparent() moves the resident index root entries into an index block and leaves a small root stub containing the child VCN. That root stub can be larger than the existing resident value. For example, an empty root with value_length 48 has an index area of 32 bytes, while the large-index root stub needs index_length and allocated_size of 40 bytes. The current code publishes the larger index.index_length and index.allocated_size before resizing the resident value. If the resize returns -ENOSPC, the recovery path can call ntfs_inode_add_attrlist(), which looks attributes up again while the root header says allocated_size 40 but the resident value still only provides 32 bytes of index area. Lookup-time $INDEX_ROOT validation then correctly rejects that transient layout as corrupt. This reproduces as a generic/013 failure under qemu. In the failing run, the transient root had value_len=48, index_size=32, index_length=40, and allocated_size=40, and ntfsprogs-plus ntfsck reported "Corrupt index root in MFT record 1177". When the root stub grows, resize the resident value before publishing the larger root header. If the resize fails, the old root remains valid for recovery lookups. Keep the existing header-before-resize ordering for shrink or same-size cases so the resident value never temporarily exposes an allocated_size beyond its bounds.
References
- nvd.nist.gov/vuln/detail/CVE-2026-72211 (opens in a new tab)
- git.kernel.org/stable/c/0bb508fb3b97e4802ec727fd2af4d608f65dd190 (opens in a new tab)
- git.kernel.org/stable/c/38d444271604afc6381ddb5a181e391915c35fae (opens in a new tab)
- ubuntu.com/security/CVE-2026-72211 (opens in a new tab)
- cve.org/CVERecord?id=CVE-2026-72211 (opens in a new tab)
- git.kernel.org/linus/0bb508fb3b97e4802ec727fd2af4d608f65dd190 (opens in a new tab)