From: Guikun Yang <yangguikun19@qq.com>
To: Konstantin Komarov <almaz.alexandrovich@paragon-software.com>
Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
ntfs3@lists.linux.dev, stable@vger.kernel.org
Subject: [PATCH] fs/ntfs3: fix log replay index walkers running past the entry chain
Date: Sat, 17 Oct 2026 00:31:29 +0800 [thread overview]
Message-ID: <tencent_46887DB8A24452C3BEAD474A9C664CDBA209@qq.com> (raw)
check_if_root_index() and check_if_alloc_index() walk the directory
entry chain of an index header until the walk offset reaches
lrh->attr_off, but they only re-check the buffer boundary at the top
of each iteration. The chain that check_index_header() validated ends
at its NTFS_IE_LAST entry; the walkers ignore that flag and keep
reading size fields from the gap between the end of the chain and
hdr->used, which is still inside the validated buffer. A crafted
$LogFile can place a size field there that jumps the walk straight to
an attr_off far outside the buffer, and the walker then reports
success.
The callers treat that result as "attr_off names a valid entry" and
act on it:
- SetIndexEntryVcnRoot/Allocation write the 8-byte log payload at
attr/ib + attr_off,
- AddIndexEntry* compute PtrOffset(e1, hdr + used) with e1 beyond
that point, which underflows to a huge length,
- Update/DeleteIndexEntry* read entry fields at the same offset.
Mounting such an image read-write therefore performs an out-of-bounds
write of controlled data at a controlled offset while replaying the
log. KASAN reports slab-out-of-bounds in log_replay() on v6.6; both
walkers are unchanged since they were introduced in b46acd6a6a62.
Stop the walk at the NTFS_IE_LAST entry so the landing offset can no
longer be driven past the end of the validated chain.
Tested on v6.6.12 and on a v7.3-rc5 based linux-next tree, both with
KASAN: with the crafted image the unpatched kernel reports
slab-out-of-bounds (write of size 8) during mount, while the patched
kernel rejects the record and the mount fails without touching memory
outside the buffer. An ordinary NTFS image still mounts read-write,
accepts writes and is readable after remount.
Fixes: b46acd6a6a62 ("fs/ntfs3: Add NTFS journal")
Cc: stable@vger.kernel.org
Signed-off-by: Guikun Yang <yangguikun19@qq.com>
---
fs/ntfs3/fslog.c | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/fs/ntfs3/fslog.c b/fs/ntfs3/fslog.c
--- a/fs/ntfs3/fslog.c
+++ b/fs/ntfs3/fslog.c
@@ -2956,6 +2956,7 @@ static inline bool check_if_root_index(const struct ATTRIB *attr,
while (o < ao) {
u16 esize;
+ bool last;
if (o >= asize)
break;
@@ -2964,8 +2965,13 @@ static inline bool check_if_root_index(const struct ATTRIB *attr,
if (!esize)
break;
+ last = de_is_last(e);
+
o += esize;
e = Add2Ptr(e, esize);
+
+ if (last)
+ break;
}
return o == ao;
@@ -2981,6 +2987,7 @@ static inline bool check_if_alloc_index(const struct INDEX_HDR *hdr,
while (o < attr_off) {
u16 esize;
+ bool last;
if (de_off >= used)
break;
@@ -2989,9 +2996,14 @@ static inline bool check_if_alloc_index(const struct INDEX_HDR *hdr,
if (!esize)
break;
+ last = de_is_last(e);
+
o += esize;
de_off += esize;
e = Add2Ptr(e, esize);
+
+ if (last)
+ break;
}
return o == attr_off;
--
2.39.5
reply other threads:[~2026-10-16 16:32 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=tencent_46887DB8A24452C3BEAD474A9C664CDBA209@qq.com \
--to=yangguikun19@qq.com \
--cc=almaz.alexandrovich@paragon-software.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=ntfs3@lists.linux.dev \
--cc=stable@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®