CVE-2026-89614: ntfs: bound the free-cluster bitmap scan to the volume
In the Linux kernel, the following vulnerability has been resolved:
ntfs: bound the free-cluster bitmap scan to the volume
vol->lcnemptybitsperpage is sized from vol->nrclusters at mount, but ntfsclusteralloc() bounds its scan of that array by the size of $Bitmap. Those are independent on-disk quantities and the mount-time check only rejects a $Bitmap that is too small, so an image whose $Bitmap covers more clusters than the volume has lets the scan index past the array. A run whose LCN lies in that gap takes the allocator straight there, since the caller passes the file's own last LCN as its locality hint. KASAN reports a slab out-of-bounds read when a file on such a volume is extended.
Clamp the scan to what that array covers, mirroring the maxindex calculation the mount-time scan already uses, and reject a decoded LCN at or beyond nrclusters in the mapping pairs decoder. Conforming volumes are unaffected.
Affected Software
Event History
Frequently Asked Questions
Who is realistically exposed to this issue?
Systems that mount a crafted or malformed NTFS volume whose $Bitmap claims more clusters than the volume contains are exposed. Conforming NTFS volumes are unaffected.
What activity triggers the out-of-bounds access?
The issue is triggered when a file on the affected NTFS volume is extended and allocation scans the free-cluster bitmap. A file run with an LCN in the gap between the actual volume cluster count and the oversized bitmap coverage can direct the allocator to the out-of-bounds array entry.
How can I determine whether a volume is affected?
An affected image has a $Bitmap that covers more clusters than the volume has; mount-time validation only rejects bitmaps that are too small. KASAN can report a slab out-of-bounds read when extending a file on such a volume.
What mitigation is available if the fix cannot be applied immediately?
Avoid mounting untrusted or malformed NTFS images, particularly where files may be extended after mounting. The described issue depends on an oversized on-disk $Bitmap rather than a conforming volume.