CVE-2026-72196

Status: UPDATED  |  Advisory ID: CVE-2026-72196

Key Details

Affected Products, Subsystems & Sectors

What to Know

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

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

In log_replay()'s analysis pass, after find_dp() returns a

valid DIR_PAGE_ENTRY for the (target_attr, target_vcn) tuple,

the copy_lcns block walks lrh->lcns_follow further entries:

t16 = le16_to_cpu(lrh->lcns_follow);

for (i = 0; i < t16; i++) {

size_t j = (size_t)(le64_to_cpu(lrh->target_vcn) -

le64_to_cpu(dp->vcn));

dp->page_lcns[j + i] = lrh->page_lcns[i];

}

find_dp() only validates that target_vcn falls within

[dp->vcn, dp->vcn + dp->lcns_follow), i.e., that the FIRST

cluster is covered. The walk through the further entries is

not bounded against dp->lcns_follow. For a malformed LRH

where target_vcn = dp->vcn + dp->lcns_follow - 1 and

lrh->lcns_follow > 1, the i > 0 writes overflow the dp's

allocated page_lcns[] array.

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

Reproduced under UML+KASAN on mainline 8d90b09e6741 as a

slab-out-of-bounds write of size 8 from log_replay+0x68d4 on

the mount path.

This is distinct from Pavitra Jha's 2026-05-02 patch

("fs/ntfs3: validate lcns_follow in log_replay conversion",

<[email protected]>) which

addresses the separate version-0 dirty-page-table conversion

path's memmove(&dp->vcn, ...) call. The two fixes are

complementary; both should land.

[[email protected]: clang-formatted the changes,

fixed conflicts] (NVD)

What to Do

Monitor Linux's web page for any future patch releases.

References