CVE-2026-89615: fs/ntfs3: bound page_lcns[] index by the log record
In the Linux kernel, the following vulnerability has been resolved:
fs/ntfs3: bound pagelcns[] index by the log record
The copylcns loop and the redo shorten loop index pagelcns[] at j + i, where i runs up to the log record's lcnsfollow. That count is checked only against the record's own length, not the target entry, so checkdptable() (which validates the entry's lcnsfollow) does not cover it: the copylcns entry may even be freshly allocated after that check, and finddp() bounds j but not i. A crafted record thus overflows pagelcns[] of an otherwise valid entry.
Add dprangeok() and reject, before each loop, any record whose run does not fit the entry. These are the only two pagelcns[] accesses indexed by the record rather than the entry, so together with the entry validation every access is now bounded.
[almaz.alexandrovich@paragon-software.com: original patch contained changes to the problem already handled, applied partly]
Affected Software
Event History
Frequently Asked Questions
What input must an attacker control to trigger this issue?
An attacker needs to provide a crafted NTFS log record with an lcns_follow run that fits the record’s own length but exceeds the capacity of the target entry’s page_lcns[] array. The vulnerable paths index the array using the record-controlled run length.
What is the impact of a successful exploit?
A crafted record can overflow page_lcns[] in an otherwise valid entry. The provided data does not specify the resulting privilege, crash behavior, or code-execution impact.
How is the issue mitigated by the fix?
The fix adds dp_range_ok() checks before both affected loops and rejects records whose run does not fit the target entry. This bounds the record-indexed page_lcns[] accesses in addition to existing entry validation.