From: Samuel Page <sam@bynar.io>
To: Konstantin Komarov <almaz.alexandrovich@paragon-software.com>
Cc: ntfs3@lists.linux.dev, linux-kernel@vger.kernel.org
Subject: [PATCH] fs/ntfs3: fix info-leak on partial LZNT decompress in ni_read_frame()
Date: Tue, 23 Jun 2026 21:00:57 +0200 [thread overview]
Message-ID: <20260623190057.12351-1-sam@bynar.io> (raw)
ni_read_frame() decompresses an LZNT $DATA frame into the vmapped target
pages and then trusts decompress_lznt()'s return value:
unc_size = decompress_lznt(frame_ondisk, ondisk_size, frame_mem,
frame_size);
if ((ssize_t)unc_size < 0) err = unc_size;
else if (!unc_size || unc_size > frame_size) err = -EINVAL;
decompress_lznt() stops as soon as the compressed stream is exhausted
(e.g. a zero chunk header) and returns the number of bytes it actually
wrote, which may be far less than frame_size. The bytes between unc_size
and frame_size are never written. The only memset() that follows zeroes
the region beyond i_valid; when the frame lies entirely within the file's
valid size that memset() does not run, so the gap retains whatever was in
the just-vmapped pages. All pages are then marked uptodate and returned
to userspace, disclosing uninitialized (recently-freed) kernel page
memory. A crafted compressed file whose stream decompresses to only a few
bytes leaks the remainder of every frame on a plain read(2), which is
enough to recover kernel pointers and defeat KASLR.
Zero the [unc_size, frame_size) tail immediately after a successful LZNT
decompress so the remainder reads back as zero.
Fixes: 4342306f0f0d ("fs/ntfs3: Add file operations and implementation")
Cc: stable@vger.kernel.org
Assisted-by: Bynario AI
Signed-off-by: Samuel Page <sam@bynar.io>
---
Reproduced on a non-KASAN, KASLR-enabled arm64 guest: a crafted file whose
64 KiB LZNT frames each decompress to 8 bytes leaks the [8, 65536) tail of
every frame on a plain read(2) - up to ~3.3 MiB of uninitialized page memory,
including kernel-text return addresses from freed VMAP_STACK pages, from
which the KASLR base was recovered and verified vs /proc/kallsyms. With the
patch the same read returns zeroes; a zeroed control image (valid_size
truncated so the existing memset runs) leaks nothing, isolating the cause.
fs/ntfs3/frecord.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/fs/ntfs3/frecord.c b/fs/ntfs3/frecord.c
index 7b035da63c12..cd11df75bdbc 100644
--- a/fs/ntfs3/frecord.c
+++ b/fs/ntfs3/frecord.c
@@ -2443,6 +2443,15 @@ int ni_read_frame(struct ntfs_inode *ni, u64 frame_vbo, struct page **pages,
err = unc_size;
else if (!unc_size || unc_size > frame_size)
err = -EINVAL;
+ else if (unc_size < frame_size) {
+ /*
+ * Partial decompress: zero the [unc_size, frame_size)
+ * tail. decompress_lznt() leaves it untouched, so
+ * without this the freshly vmapped pages would expose
+ * uninitialized kernel memory to userspace.
+ */
+ memset(frame_mem + unc_size, 0, frame_size - unc_size);
+ }
}
if (!err && valid_size < frame_vbo + frame_size) {
size_t ok = valid_size - frame_vbo;
--
2.54.0
next reply other threads:[~2026-06-23 19:01 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-23 19:00 Samuel Page [this message]
2026-07-28 9:53 ` [PATCH] fs/ntfs3: fix info-leak on partial LZNT decompress in ni_read_frame() Konstantin Komarov
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=20260623190057.12351-1-sam@bynar.io \
--to=sam@bynar.io \
--cc=almaz.alexandrovich@paragon-software.com \
--cc=linux-kernel@vger.kernel.org \
--cc=ntfs3@lists.linux.dev \
/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