CVE-2026-98139: ntfs: only count successfully cleared runs when freeing clusters
In the Linux kernel, the following vulnerability has been resolved:
ntfs: only count successfully cleared runs when freeing clusters
ntfsclusterfreefromrlnolock() adds a run's length to nrfreed whenever the error bookkeeping condition is false, which includes cases where ntfsbitmapclearrun() actually failed - e.g. a second run failing with the same errno as an earlier one, or any failure after a non-ENOMEM error was already recorded. Since a failed ntfsbitmapclearrun() rolls back its partial modifications, no bits were cleared for that run, yet its length still inflates vol->freeclusters, corrupting statfs output and the allocator's free space gate.
Only count runs whose bitmap clear succeeded.
Affected Software
Event History
Frequently Asked Questions
What conditions can trigger the free-space accounting corruption?
The issue can occur when clearing an NTFS bitmap run fails but the function still adds that run's length to the freed-cluster count. Examples given include a second run failing with the same errno as an earlier failure, or a failure occurring after a non-ENOMEM error has already been recorded.
What is the practical impact on an affected system?
The volume's free_clusters value can be inflated even though the failed bitmap operation cleared no bits. This can corrupt statfs free-space reporting and affect the allocator's free-space gate.
How can administrators tell whether a failed run was actually freed?
A failed ntfs_bitmap_clear_run() rolls back its partial changes, so no bitmap bits are cleared for that run. The affected behavior is an accounting mismatch: free-space counters may increase despite the bitmap clear operation failing.