CVE-2026-72196: fs/ntfs3: bound copy_lcns dp->page_lcns[] index in analysis pass

In the Linux kernel, the following vulnerability has been resolved:

fs/ntfs3: bound copylcns dp->pagelcns[] index in analysis pass

In logreplay()'s analysis pass, after finddp() returns a valid DIRPAGEENTRY for the (targetattr, targetvcn) tuple, the copylcns block walks lrh->lcnsfollow further entries:

t16 = le16tocpu(lrh->lcnsfollow); for (i = 0; i < t16; i++) { sizet j = (sizet)(le64tocpu(lrh->targetvcn) - le64tocpu(dp->vcn)); dp->pagelcns[j + i] = lrh->pagelcns[i]; }

finddp() only validates that targetvcn falls within [dp->vcn, dp->vcn + dp->lcnsfollow), i.e., that the FIRST cluster is covered. The walk through the further entries is not bounded against dp->lcnsfollow. For a malformed LRH where targetvcn = dp->vcn + dp->lcnsfollow - 1 and lrh->lcnsfollow > 1, the i > 0 writes overflow the dp's allocated pagelcns[] array.

Add the missing j + lrh->lcnsfollow <= dp->lcnsfollow guard.

Reproduced under UML+KASAN on mainline 8d90b09e6741 as a slab-out-of-bounds write of size 8 from logreplay+0x68d4 on the mount path.

This is distinct from Pavitra Jha's 2026-05-02 patch ("fs/ntfs3: validate lcnsfollow in logreplay conversion", <20260502154252.164586-1-jhapavitra98@gmail.com>) which addresses the separate version-0 dirty-page-table conversion path's memmove(&dp->vcn, ...) call. The two fixes are complementary; both should land.

[almaz.alexandrovich@paragon-software.com: clang-formatted the changes, fixed conflicts]