fs/ntfs3: reject index allocation if $BITMAP is empty but blocks exist
Affects the Linux kernel ntfs3 driver when it handles a malformed NTFS image whose $BITMAP is empty while index blocks exist. Fixed in the 6.6.112, 6.12.53, and 6.17.3 stable releases.
- Published
- Last modified
- Where the record stands: published, rejected by its publisher, or superseded by another id.What do these mean? →
- published
- Whether CISA lists it in its Known Exploited Vulnerabilities catalog: proof that attackers are using it.What do these mean? →
- Not listed in CISA KEV
- How many real-world setups can hit the bug, from the vendor's advisory and CISA data. It does not know your setup.What do these mean? →
- Specific setups only
- Fix
- Fixed in 6.6.112, 6.12.53, 6.16, 6.17, 6.17.3
- Whether working attack code is public (Exploit-DB, Metasploit, Nuclei or GitHub). Public code makes attacks easier.What do these mean? →
- None on Exploit-DB, Metasploit or GitHub
Summary
In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: reject index allocation if $BITMAP is empty but blocks exist Index allocation requires at least one bit in the $BITMAP attribute to track usage of index entries. If the bitmap is empty while index blocks are already present, this reflects on-disk corruption. syzbot triggered this condition using a malformed NTFS image. During a rename() operation involving a long filename (which spans multiple index entries), the empty bitmap allowed the name to be added without valid tracking. Subsequent deletion of the original entry failed with -ENOENT, due to unexpected index state. Reject such cases by verifying that the bitmap is not empty when index blocks exist.
Timeline
- CVE published
- Record last updated
Affected versions
- Linux Linux
From 6.6.102 · fixed in 6.6.112; From 6.12.42 · fixed in 6.12.53; From 6.15.10 · fixed in 6.16; From 6.16.1 · fixed in 6.17
- Linux Linux
6.17
- KernelLinux
fixed in 6.6.112; From 6.7.0 · fixed in 6.12.53; From 6.13.0 · fixed in 6.17.3
References 5
Questions about CVE-2025-40067
What does this mean?
The ntfs3 driver accepted an index allocation on an NTFS volume whose $BITMAP is empty even though index blocks already exist. The fix makes the kernel reject that state. The condition is on-disk corruption in the NTFS image.Source: git.kernel.org
Am I affected, and how do I check?
The listed ranges are Linux kernel 6.6.102 up to 6.6.112, 6.12.42 up to 6.12.53, 6.15.10 up to 6.16, and 6.16.1 up to 6.17. Check the running kernel with uname -r and compare it to these ranges. The bug only involves NTFS images with an empty $BITMAP and existing index blocks.Source: git.kernel.org
What should I do about it?
Update to a fixed kernel: 6.6.112 or later on the 6.6 line, 6.12.53 or later on the 6.12 line, 6.16 or later on the 6.15/6.16 line, or 6.17.3 or later on the 6.17 line.Source: git.kernel.org
Is it being exploited?
It is not in CISA's Known Exploited Vulnerabilities catalog, and CISA's SSVC assessment does not mark exploitation as active. That does not mean it has not been attacked: vendors and researchers can report attacks before CISA lists them. No public exploit code is tracked.Source: cve.now feed data