CVE-2026-64432: fs/ntfs3: validate Dirty Page Table capacity in log_replay copy_lcns
In the Linux kernel, the following vulnerability has been resolved:
fs/ntfs3: validate Dirty Page Table capacity in logreplay copylcns
In the analysis pass of $LogFile journal replay, logreplay() copies LCNs from each action log record into an existing Dirty Page Table (DPT) entry without bounding the destination index. A crafted NTFS image with DPT entry lcnsfollow=1 and an action log record with lcnsfollow=2 produces a kernel slab out-of-bounds write at mount time:
BUG: KASAN: slab-out-of-bounds in logreplay+0x654c/0xdb60 Write of size 8 at addr ffff8880095e1040 by task mount
Two attacker-controlled fields can drive j+i past the allocated pagelcns[] array:
1. dp->lcnsfollow (capacity) can be smaller than lrh->lcnsfollow. 2. lrh->targetvcn may be smaller than dp->vcn, making the u64 subtraction wrap to a huge sizet.
Validate target VCN delta and per-record LCN count against the DPT entry capacity, bail via the existing out: cleanup label with -EINVAL.
This mirrors the bounds-check pattern added in commit b2bc7c44ed17 ("fs/ntfs3: Fix slab-out-of-bounds read in DeleteIndexEntryRoot") and commit 0ca0485e4b2e ("fs/ntfs3: validate rec->used in journal-replay file record check").
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
Linux kernel fs/ntfs3to a version that resolves this vulnerability.Patch b2bc7c44ed17 - Upgrade
Upgrade
Linux kernel fs/ntfs3to a version that resolves this vulnerability.Patch 0ca0485e4b2e - Configuration
Apply the fs/ntfs3 fix so log_replay() validates lrh->target_vcn delta and validates per-record LCN count against dp->lcns_follow capacity before copying LCNs into dp->page_lcns[] to prevent slab out-of-bounds read/write during $LogFile journal replay.
Linux kernel fs/ntfs3 Dirty Page Table (DPT) lcns_follow = validate target VCN delta and per-record LCN count against DPT entry capacity (bail via existing out/cleanup label)
Event History
Frequently Asked Questions
Which systems are realistically exposed?
Systems that mount attacker-controlled NTFS images are exposed, because the out-of-bounds write occurs during $LogFile journal replay at mount time. The CVSS vector is local and requires user interaction.
What does an attacker need to trigger the issue?
An attacker needs to provide a crafted NTFS image containing inconsistent Dirty Page Table and action log record values, then have it mounted. Specifically, the image can use an LCN count larger than the allocated DPT capacity or a target VCN below the DPT VCN.
What can be done before the relevant kernel fix is deployed?
Avoid mounting untrusted or attacker-supplied NTFS images, particularly where their journal contents cannot be trusted. The vulnerable processing is reached while mounting the crafted filesystem image.
How might the issue appear on an affected system?
With KASAN enabled, triggering input can produce a slab-out-of-bounds report in log_replay during a mount operation, including an 8-byte write. The reported task may be mount.