CVE-2026-89615
massOut-of-bounds write in Linux kernel ntfs3 log replay via crafted NTFS journal records
The Linux kernel's NTFS3 filesystem driver (fs/ntfs3) contains an out-of-bounds write of the page_lcns[] array during $Logfile replay: the copy_lcns loop and the redo-shorten loop index the array at j + i, where i runs up to the log record's lcns_follow value, but that count is validated only against the record's own length rather than against the target entry's allocated size. An attacker triggers the flaw by getting the kernel to mount and replay the journal of a crafted NTFS volume — for example a malicious USB drive or a hostile disk/container image — which explains the CVSS 3.1 score of 8.4 with a local attack vector requiring no privileges or user interaction (e.g., desktop auto-mount scenarios). Successful exploitation corrupts kernel heap memory adjacent to the overflowed array, which can crash the system or enable kernel-level code execution and privilege escalation. Any Linux system whose kernel includes the ntfs3 driver and that mounts attacker-influenced NTFS media is affected; the fix adds a dp_range_ok() check rejecting records whose run does not fit the entry before each loop. No public proof-of-concept exists and the flaw is not in the CISA KEV catalog, so exploitation is not currently known.
What to do: Patch to a kernel release containing the fs/ntfs3 fix that adds the dp_range_ok() validation, following your distribution's stable-kernel advisory once the fix is backported. Until then, disable auto-mounting of removable NTFS media (udisks/PolicyKit), avoid mounting untrusted NTFS images or volumes, and blacklist the ntfs3 module via modprobe if it is not needed. Investigate any kernel oops or BUG triggered during NTFS mount or log replay as a possible exploitation indicator.
| Linux kernel with the fs/ntfs3 NTFS driver (CONFIG_NTFS3) | All kernel releases shipping fs/ntfs3 prior to the commit adding the dp_range_ok() bounds check; the advisory does not specify a fixed release version |
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: fs/ntfs3: bound page_lcns[] index by the log record The copy_lcns loop and the redo shorten loop index page_lcns[] at j + i, where i runs up to the log record's lcns_follow. That count is checked only against the record's own length, not the target entry, so check_dp_table() (which validates the entry's lcns_follow) does not cover it: the copy_lcns entry may even be freshly allocated after that check, and find_dp() bounds j but not i. A crafted record thus overflows page_lcns[] of an otherwise valid entry. Add dp_range_ok() and reject, before each loop, any record whose run does not fit the entry. These are the only two page_lcns[] accesses indexed by the record rather than the entry, so together with the entry validation every access is now bounded. [[email protected]: original patch contained changes to the problem already handled, applied partly]
- Vector
- CVSS:3.1/AV:L/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.