CVE-2026-89614
largeOut-of-bounds read in Linux kernel NTFS driver via oversized $Bitmap
The Linux kernel's legacy NTFS driver sizes its free-cluster bitmap summary array from the volume's nr_clusters at mount time, but ntfs_cluster_alloc() bounds its scan of that array by the on-disk $Bitmap size, and those two quantities are independent. A crafted NTFS image whose $Bitmap claims to cover more clusters than the volume actually contains lets the scan index past the end of the array, and extending a file on such a volume steers the allocator directly into the out-of-range region because the file's own last LCN is passed as the locality hint. KASAN reports this as a slab out-of-bounds read, so an attacker who can get a system to mount a malicious NTFS filesystem (for example via removable media or a supplied disk image) could plausibly read adjacent kernel memory or crash the kernel; the CVSS 9.8 network-vector rating overstates practical reachability since mounting the crafted volume is required. Systems running unfixed kernels that use the legacy in-kernel ntfs driver are affected, while conforming NTFS volumes are unaffected and users of the newer ntfs3 driver or the ntfs-3g FUSE driver are not exposed to this code path. No public proof of concept exists and no exploitation in the wild has been reported.
What to do: Apply a kernel update containing this fix as soon as your distribution ships one, since exact fixed versions were not specified in the source data. Until patched, avoid mounting untrusted NTFS images or removable media, and consider disabling or blacklisting the legacy ntfs module (CONFIG_NTFS_FS) in favor of ntfs3 or ntfs-3g. Conforming NTFS volumes are unaffected, so existing legitimate volumes do not trigger this bug.
| Linux kernel (legacy ntfs filesystem driver, CONFIG_NTFS_FS) | — |
Order-of-magnitude estimate by the model from install counts, market share and public scan data it knows; verify before quoting.
In the Linux kernel, the following vulnerability has been resolved: ntfs: bound the free-cluster bitmap scan to the volume vol->lcn_empty_bits_per_page is sized from vol->nr_clusters at mount, but ntfs_cluster_alloc() 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 max_index calculation the mount-time scan already uses, and reject a decoded LCN at or beyond nr_clusters in the mapping pairs decoder. Conforming volumes are unaffected.
- Vector
- CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
In the news0 stories
No ingested article mentions this CVE yet.