From: rtm@csail.mit.edu
To: Konstantin Komarov <almaz.alexandrovich@paragon-software.com>
Cc: ntfs3@lists.linux.dev
Subject: write past end of buffer in ntfs3's mi_pack_runs()
Date: Thu, 03 Sep 2026 09:14:45 -0400 [thread overview]
Message-ID: <26453.1788441285@localhost> (raw)
If the NTFS file system is corrupt, it's possible for this memmove()
in mi_pack_runs() to write past the end of mi->mrec:
memmove(next + new_run_size - run_size, next + dsize, tail);
Here's a demo; the overflow happens during attempted file creation,
but the redzone violation is only discovered during unmount.
# uname -a
Linux xxx 7.3.0-rc1-00099-g89a312991dc6 #42 SMP PREEMPT_DYNAMIC Wed Sep 2 12:17:14 EDT 2026 x86_64 x86_64 x86_64 GNU/Linux
# wget http://www.rtmrtm.org/rtm/ntfs19b.img.gz
# gunzip ntfs19b.img.gz
# mount -t ntfs3 -o loop ntfs19b.img /mnt
# echo z > /mnt/z
ntfs3(loop0): ino=0, mi_enum_attr
ntfs3(loop0): ino=0, attr_set_size_ex
/mnt/z: No such file or directory.
# umount /mnt
[Right Redzone overwritten] 0xffff888103350800-0xffff888103350806 @offset=2048. First byte 0x0 instead of 0xcc
=============================================================================
BUG kmalloc-1k (Not tainted): Object corrupt
-----------------------------------------------------------------------------
Allocated in mi_init+0x21/0x40 age=14359 cpu=4 pid=4860
Freed in ni_clear+0xf7/0x1e0 age=14359 cpu=4 pid=4860
Here's a back-trace at the overflowing call to memmove():
#0 __pi___memmove () at arch/riscv/lib/memmove.S:28
#1 0xffffffff8049c35e in mi_pack_runs (mi=0xffffffd6022e9388,
attr=0xffffffd603872900, run=run@entry=0xffffffd6022e94b8,
len=<optimized out>) at fs/ntfs3/record.c:705
#2 0xffffffff8047b704 in attr_set_size_ex (ni=ni@entry=0xffffffd6022e9388,
type=type@entry=ATTR_DATA, name=name@entry=0x0,
name_len=name_len@entry=0 '\000', run=run@entry=0xffffffd6022e94b8,
new_size=new_size@entry=1179648, new_valid=new_valid@entry=0x0,
keep_prealloc=keep_prealloc@entry=false, ret=ret@entry=0xffffffc60024b950,
no_da=no_da@entry=false) at fs/ntfs3/attrib.c:680
#3 0xffffffff80484130 in ntfs_extend_mft (sbi=sbi@entry=0xffffffd603ba0800)
at fs/ntfs3/fsntfs.c:544
#4 0xffffffff8048439c in ntfs_look_free_mft (
sbi=sbi@entry=0xffffffd603ba0800, rno=rno@entry=0xffffffc60024bae0,
mft=mft@entry=false, ni=ni@entry=0x0, mi=mi@entry=0x0)
at fs/ntfs3/fsntfs.c:759
#5 0xffffffff804955c2 in ntfs_create_inode (
idmap=0xffffffff816b7208 <nop_mnt_idmap>, dir=0xffffffd6022ec1c0,
dentry=0xffffffd60217ad70, uni=uni@entry=0x0, mode=33206, dev=dev@entry=0,
symname=symname@entry=0x0, size=size@entry=0, fnd=fnd@entry=0x0)
at fs/ntfs3/inode.c:1526
#6 0xffffffff8049abb4 in ntfs_create (idmap=<optimized out>,
dir=<optimized out>, dentry=<optimized out>, mode=<optimized out>)
at fs/ntfs3/namei.c:117
#7 0xffffffff8030b3f0 in lookup_open (nd=nd@entry=0xffffffc60024bce8,
file=file@entry=0xffffffd603a9b1c0, op=op@entry=0xffffffc60024be10)
at fs/namei.c:4575
Robert Morris
rtm@mit.edu
reply other threads:[~2026-09-03 13:40 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=26453.1788441285@localhost \
--to=rtm@csail.mit.edu \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.