From: lei lu <llfamsec@gmail.com>
To: llfamsec@gmail.com
Cc: almaz.alexandrovich@paragon-software.com, ntfs3@lists.linux.dev
Subject: Re: [PATCH v2] ntfs3: Add bounds checking to enum_rstbl()
Date: Thu, 19 Sep 2024 01:43:24 +0800 [thread overview]
Message-ID: <20240918174324.555381-1-llfamsec@gmail.com> (raw)
In-Reply-To: <20240918171720.555304-1-llfamsec@gmail.com>
Hi, Konstantin,
In log_replay, enum_rstbl didn't check the real size of the entry. It
traverses based on RESTART_TABLE.size. There is a lack of boundary check
if the real size is not equal to RESTART_TABLE.size.
Here is a PoC to reproduce.
PoC:
1) Found NTFS_RESTART by CLIENT_REC[0].restart_lsn
NTFS_RESTART.open_attr_table_lsn: LSN where PoC is located
NTFS_RESTART.open_attr_len: 0x1
2) Layout PoC as follow in a LSN area as follow:
LFS_RECORD_HDR.this_lsn: 0x28455b
LFS_RECORD_HDR.client_prev_lsn: 0x0
LFS_REOCRD_HDR.client_undo_next_lsn: 0x0
LFS_RECORD_HDR.client_data_len: 0x98
LFS_RECORD_HDR.CLIENT_ID.seq_num: 0x0
LFS_RECORD_HDR.CLIENT_ID.client_idx: 0x0
LFS_RECORD_HDR.record_type: 0x1
LFS_RECORD_HDR.transact_id: 0x18
LFS_RECORD_HDR.flags: 0x4
LOG_REC_HDR.redo_op: 0x0
LOG_REC_HDR.undo_op: 0x0
LOG_REC_HDR.redo_off: 0x98-sizeof(RESTART_TABLE)-RESTART_TABLE.size (redo_off&7 != 0)
LOG_REC_HDR.redo_len: 0x0
LOG_REC_HDR.undo_off: 0x0
LOG_REC_HDR.undo_len: 0x0
LOG_REC_HDR.target_attr: 0x0
LOG_REC_HDR.lcns_follow: 0x0
LOG_REC_HDR.record_off: 0x0
LOG_REC_HDR.attr_off: 0x0
LOG_REC_HDR.cluster_off: 0x0
LOG_REC_HDR.reserved: 0x0
LOG_REC_HDR.target_vcn: 0x0
LOG_REC_HDR.page_lcns[0]: 0x0
RESTART_TABLE.size: 8
RESTART_TABLE.used: 0x1
RESTART_TABLE.total: 0x1
RESTART_TABLE.res[0]: 0x0
RESTART_TABLE.res[1]: 0x0
RESTART_TABLE.res[2]: 0x0
RESTART_TABLE.free_goal: 0x0
RESTART_TABLE.first_free: 0x0
RESTART_TABLE.last_free: 0x0
entry[0][0:4]: 0xFFFFFFFF (OPEN_ATTR_ENRTY[0].next)
OPEN_ATTR_ENRTY[0].bytes_per_index: 0x0
In the patch, taking DIR_PAGE_ENTRY_32/DIR_PAGE_ENTRY as an example, there are two
situations:
[1] https://elixir.bootlin.com/linux/v6.10-rc4/source/fs/ntfs3/fslog.c#L4186
If entry is DIR_PAGE_ENTRY_32, it seems to explain it as DIR_PAGE_ENTRY, but the
entry size is still DIR_PAGE_ENTRY_32, so we use sizeof(struct DIR_PAGE_ENTRY_32)
[2] https://elixir.bootlin.com/linux/v6.10-rc4/source/fs/ntfs3/fslog.c#L4206
- If entry is DIR_PAGE_ENTRY directly, we use sizeof(*dp)
- If entry is DIR_PAGE_ENTRY_32, but it is explained as DIR_PAGE_ENTRY. Because
We check it in [1], and sizeof(struct DIR_PAGE_ENTRY) is smaller, so we also
use sizeof(*dp)
Thanks,
LL
next prev parent reply other threads:[~2024-09-18 17:43 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-09-18 17:17 [PATCH v2] ntfs3: Add bounds checking to enum_rstbl() lei lu
2024-09-18 17:43 ` lei lu [this message]
-- strict thread matches above, loose matches on Subject: below --
2024-07-09 3:48 lei lu
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=20240918174324.555381-1-llfamsec@gmail.com \
--to=llfamsec@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