From: rtm@csail.mit.edu
To: almaz.alexandrovich@paragon-software.com
Cc: ntfs3@lists.linux.dev
Subject: mi_enum_attr() has insufficient check on attr->res.data_size
Date: Sat, 27 Jan 2024 06:06:27 -0500 [thread overview]
Message-ID: <71075.1706353587@localhost> (raw)
[-- Attachment #1: Type: text/plain, Size: 2234 bytes --]
I've attached a corrupt ntfs image that causes fs/ntfs3 to write past
the end of a buffer.
The start of the problem is that mi_enum_attr() uses this to check that
the data_size in an ATTRIB is OK:
t16 = le16_to_cpu(attr->res.data_off);
if (t16 + le32_to_cpu(attr->res.data_size) > asize)
return NULL;
If attr->res.data_size is huge, e.g. 0xfffffff0, then the sum can wrap
so that it is less than asize. This means that mi_enum_attr() can accept
a huge data_size.
That in turn means that indx_get_root()'s check that root->ihdr.used
is less than a->res.data_size can allow root->ihdr.used to be huge:
/* length check */
if (root &&
offsetof(struct INDEX_ROOT, ihdr) + le32_to_cpu(root->ihdr.used) >
le32_to_cpu(a->res.data_size)) {
return NULL;
}
A huge hdr->used can allow hdr_insert_de() to pass a large byte-count
to memmove(), causing it to write past the end of the allocated block
containing before:
u32 used = le32_to_cpu(hdr->used);
...;
memmove(Add2Ptr(before, de_size), before, used - off);
That's what the attached image provokes; the hdr->used in question is
3032, which is larger than the 1024-byte sbi->record_size.
# uname -a
Linux ubuntu66 6.7.0-11091-g296455ade1fd #5 SMP PREEMPT_DYNAMIC Fri Jan 19 15:38:07 EST 2024 x86_64 x86_64 x86_64 GNU/Linux
# gunzip -c < ntfs22c.img.gz > ntfs22c.img
# while :
do
mount -t ntfs3 -o loop,rw ntfs22c.img /mnt
touch /mnt/x /mnt/y
rm /mnt/[xy]
umount /mnt
done
=============================================================================
BUG kmalloc-1k (Tainted: G W ): Left Redzone overwritten
-----------------------------------------------------------------------------
0xffff888121d79800-0xffff888121d7982f @offset=6144. First byte 0x5a instead of 0xcc
Allocated in mi_init+0x7c/0x110 age=32936 cpu=7 pid=1359
Freed in qlist_free_all+0x56/0x170 age=48398 cpu=10 pid=1249
Slab 0xffffea0004875e00 objects=10 used=9 fp=0xffff888121d7c000 flags=0x20000000
0000a40(workingset|slab|head|node=0|zone=2)
Object 0xffff888121d79c00 @offset=7168 fp=0xffff888121d7a800
Robert Morris
rtm@csail.mit.edu
[-- Attachment #2: ntfs22c.img.gz --]
[-- Type: application/octet-stream, Size: 124414 bytes --]
reply other threads:[~2024-01-27 11:06 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=71075.1706353587@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).