From: 0xkato <0xkkato@gmail.com>
To: almaz.alexandrovich@paragon-software.com
Cc: ntfs3@lists.linux.dev, 0xkato <0xkkato@gmail.com>
Subject: [PATCH] ntfs3: fix OOB write in attr_wof_frame_info()
Date: Sun, 29 Mar 2026 13:57:57 +0200 [thread overview]
Message-ID: <20260329115757.66040-1-0xkkato@gmail.com> (raw)
In attr_wof_frame_info(), the offset-table read range for a nonresident
WofCompressedData stream is:
u64 from = vbo[i] & ~(u64)(PAGE_SIZE - 1);
u64 to = min(from + PAGE_SIZE, wof_size);
...
ntfs_read_run(sbi, run, addr, from, to - from);
A crafted image sets WofCompressedData.nres.data_size to 0xfff while the
file is large enough to request frame 1024 (offset 0x400000). This gives
from=0x1000, to=0xfff. The unsigned (to - from) wraps to 0xffffffffffffffff
and ntfs_read_write_run() overflows the single-page offs_folio via memcpy.
Triggered by pread() on a mounted NTFS image. Depending on adjacent
memory layout at the time of the overflow, KASAN reports this as
slab-out-of-bounds, use-after-free, or slab-use-after-free all at
ntfs_read_write_run(). Secondary corruption/panic paths were also observed.
Reject the read when the offset-table page is outside the stream.
Signed-off-by: 0xkato <0xkkato@gmail.com>
---
Reproducer:
Create the crafted NTFS image:
python3 create_wof_poc.py -o wof-poc.img
Mount it read-only with ntfs3:
sudo mount -t ntfs3 -o loop,ro wof-poc.img /mnt
Build the trigger:
cc -O2 -static wof_offset_table_read_trigger.c -o trigger
Trigger the bug:
./trigger /mnt/poc.bin 0x400000 1
KASAN report on 6.19.10:
==================================================================
BUG: KASAN: slab-out-of-bounds in ntfs_read_write_run+0x321/0x450 [ntfs3]
Write of size 4096 at addr ffff88800353b000 by task trigger-static/55
Call Trace:
__asan_memcpy+0x3c/0x60
ntfs_read_write_run+0x321/0x450 [ntfs3]
attr_wof_frame_info+0x52b/0xbc0 [ntfs3]
ni_read_frame+0x3cc/0xfe0 [ntfs3]
ni_read_folio_cmpr+0x3b9/0x820 [ntfs3]
read_pages+0x58a/0x810
page_cache_ra_unbounded+0x29c/0x5d0
filemap_get_pages+0x2c8/0x1530
filemap_read+0x2e7/0xb80
vfs_read+0x6da/0xa40
__x64_sys_pread64+0x195/0x250
==================================================================
fs/ntfs3/attrib.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/fs/ntfs3/attrib.c b/fs/ntfs3/attrib.c
index 6cb9bc5d6..89921e509 100644
--- a/fs/ntfs3/attrib.c
+++ b/fs/ntfs3/attrib.c
@@ -1576,6 +1576,12 @@ int attr_wof_frame_info(struct ntfs_inode *ni, struct ATTRIB *attr,
u64 from = vbo[i] & ~(u64)(PAGE_SIZE - 1);
u64 to = min(from + PAGE_SIZE, wof_size);
+ if (from >= wof_size) {
+ _ntfs_bad_inode(&ni->vfs_inode);
+ err = -EINVAL;
+ goto out1;
+ }
+
err = attr_load_runs_range(ni, ATTR_DATA, WOF_NAME,
ARRAY_SIZE(WOF_NAME), run,
from, to);
--
2.50.1 (Apple Git-155)
next reply other threads:[~2026-03-29 11:58 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-29 11:57 0xkato [this message]
2026-03-29 11:59 ` [PATCH] ntfs3: fix OOB write in attr_wof_frame_info() 0x Kato
2026-04-07 17:20 ` 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=20260329115757.66040-1-0xkkato@gmail.com \
--to=0xkkato@gmail.com \
--cc=almaz.alexandrovich@paragon-software.com \
--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