CVE-2026-89617: fs/ntfs3: validate dirty page table on log replay
In the Linux kernel, the following vulnerability has been resolved:
fs/ntfs3: validate dirty page table on log replay
Each DIRPAGEENTRY ends in a pagelcns[] array whose length is the on-disk lcnsfollow field. checkrstbl() validates the table bookkeeping but never checks that this array fits in the entry, so a crafted lcnsfollow lets the v0->v1 conversion memmove and later replay passes run off the entry.
Add checkdptable() to reject, right after checkrstbl(), any entry larger than its size claims via structsize() (the same expression used to allocate these entries, so the check is overflow-safe by construction). All consumers can then trust lcnsfollow as the real capacity. This covers every pagelcns[] access whose index is bounded by the entry itself (the conversion memmove, the HotFix store via finddp(), and the self-bounded scan loops). Accesses whose index comes from the log record need a separate bound and are handled in a follow-up patch.
Affected Software
Event History
Frequently Asked Questions
When can this flaw be reached?
It is reached during NTFS3 log replay when processing a dirty page table entry whose on-disk lcns_follow value makes the page_lcns[] array larger than the entry permits.
What attacker-controlled condition is required?
An attacker needs to supply crafted on-disk dirty page table data with an invalid lcns_follow value. That value can cause conversion and replay processing to access memory beyond the affected entry.
What does the fix validate?
The fix rejects dirty page table entries whose claimed page_lcns[] size exceeds the entry size calculated with struct_size(). This makes lcns_follow trustworthy for accesses bounded by the entry itself.