From: Xingyuan Mo <hdthky0@gmail.com>
To: Carlos Maiolino <cem@kernel.org>
Cc: "open list:XFS FILESYSTEM" <linux-xfs@vger.kernel.org>,
open list <linux-kernel@vger.kernel.org>,
Xingyuan Mo <hdthky0@gmail.com>
Subject: [PATCH] xfs: validate dquot buffer geometry in dquot log recovery
Date: Fri, 13 Nov 2026 19:01:47 +0800 [thread overview]
Message-ID: <20261113110128.4001610-1-hdthky0@gmail.com> (raw)
xlog_recover_dquot_commit_pass2() has never really validated the dquot
log item. The only check on qlf_len is a DEBUG-only ASSERT, and
qlf_boffset goes straight into xfs_buf_offset() to pick the dquot slot
inside the chunk buffer:
dqb = xfs_buf_offset(bp, dq_f->qlf_boffset);
...
memcpy(ddq, recddq, item->ri_buf[1].iov_len);
Both the offset and the length of the memcpy come from the journal of
the filesystem being mounted, so a crafted log can make mount time
replay write past the end of the chunk buffer. Sub-page block sizes
get an exact-size kmalloc for the buffer, so an offset of one blocksize
lands right on the KASAN redzone; larger offsets are wild writes. On
CRC filesystems the dd_lsn load in between is out of bounds too. The
recovery regions are allocated to the logged length, so a short region
0 also turns the qlf_* dereferences into out-of-bounds reads.
Make this code validate the item like the rest of log recovery does:
both regions must be exactly the expected size, qlf_len must be 1, and
qlf_boffset must point inside the buffer that is about to be read.
The readahead path gets the region length and qlf_len checks too.
I reproduced this on a v4 filesystem with 512-byte blocks and user
quota enabled: force a few dquot transactions into the log, crash the
box so they stay dirty, rewrite qlf_boffset of the on-disk XFS_LI_DQUOT
items to 512 (one block past bp->b_addr) and mount. Without the fix,
replay trips KASAN:
BUG: KASAN: slab-out-of-bounds in xlog_recover_dquot_commit_pass2+0x32a/0x500
Write of size 104 at addr ffff88801c8b0200 by task mount/430
CPU: 0 UID: 0 PID: 430 Comm: mount Not tainted 7.4.0-rc2-00021-gb3dfbde62cf1 #44 PREEMPT(lazy)
Call Trace:
<TASK>
dump_stack_lvl+0x73/0xb0
print_report+0xd1/0x610
kasan_report+0xff/0x130
kasan_check_range+0x10c/0x1c0
__asan_memcpy+0x3f/0x70
xlog_recover_dquot_commit_pass2+0x32a/0x500
xlog_recover_items_pass2+0x7d/0x1b0
xlog_recover_commit_trans+0x585/0x630
xlog_recovery_process_trans+0xe2/0xf0
xlog_recover_process_ophdr+0xf8/0x1d0
xlog_recover_process_data+0x126/0x270
xlog_recover_process+0x132/0x210
xlog_do_recovery_pass+0x6be/0x8f0
xlog_do_log_recovery+0x65/0x90
xlog_do_recover+0x7d/0x2b0
xlog_recover+0x1bc/0x2d0
xfs_log_mount+0x17b/0x2c0
xfs_mountfs+0x70a/0xe70
xfs_fs_fill_super+0xaca/0xf60
get_tree_bdev+0x14/0x20
xfs_fs_get_tree+0x19/0x20
vfs_get_tree+0x54/0x170
path_mount+0x4ad/0x13a0
__x64_sys_mount+0x1dd/0x210
do_syscall_64+0x10b/0x5f0
entry_SYSCALL_64_after_hwframe+0x77/0x7f
</TASK>
With the fix the same image is rejected without any out-of-bounds
access, and a pristine dirty log still recovers fine:
XFS (loop2): log mount/recovery failed: error -117
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by: Xingyuan Mo <hdthky0@gmail.com>
---
fs/xfs/xfs_dquot_item_recover.c | 17 ++++++++++++++---
1 file changed, 14 insertions(+), 3 deletions(-)
diff --git a/fs/xfs/xfs_dquot_item_recover.c b/fs/xfs/xfs_dquot_item_recover.c
index b8854316ac756..3172efb94c277 100644
--- a/fs/xfs/xfs_dquot_item_recover.c
+++ b/fs/xfs/xfs_dquot_item_recover.c
@@ -47,7 +47,9 @@ xlog_recover_dquot_ra_pass2(
dq_f = item->ri_buf[0].iov_base;
ASSERT(dq_f);
- ASSERT(dq_f->qlf_len == 1);
+ if (item->ri_buf[0].iov_len != sizeof(struct xfs_dq_logformat) ||
+ dq_f->qlf_len != 1)
+ return;
xlog_buf_readahead(log, dq_f->qlf_blkno,
XFS_FSB_TO_BB(mp, dq_f->qlf_len),
@@ -84,7 +86,7 @@ xlog_recover_dquot_commit_pass2(
xfs_alert(log->l_mp, "NULL dquot in %s.", __func__);
return -EFSCORRUPTED;
}
- if (item->ri_buf[1].iov_len < sizeof(struct xfs_disk_dquot)) {
+ if (item->ri_buf[1].iov_len != sizeof(struct xfs_disk_dquot)) {
xfs_alert(log->l_mp, "dquot too small (%zd) in %s.",
item->ri_buf[1].iov_len, __func__);
return -EFSCORRUPTED;
@@ -110,13 +112,22 @@ xlog_recover_dquot_commit_pass2(
*/
dq_f = item->ri_buf[0].iov_base;
ASSERT(dq_f);
+
+ if (item->ri_buf[0].iov_len != sizeof(struct xfs_dq_logformat))
+ return -EFSCORRUPTED;
+
fa = xfs_dquot_verify(mp, recddq, dq_f->qlf_id);
if (fa) {
xfs_alert(mp, "corrupt dquot ID 0x%x in log at %pS",
dq_f->qlf_id, fa);
return -EFSCORRUPTED;
}
- ASSERT(dq_f->qlf_len == 1);
+ if (dq_f->qlf_len != 1)
+ return -EFSCORRUPTED;
+
+ if (dq_f->qlf_boffset > BBTOB(XFS_FSB_TO_BB(mp, dq_f->qlf_len)) -
+ sizeof(struct xfs_dqblk))
+ return -EFSCORRUPTED;
/*
* At this point we are assuming that the dquots have been allocated
--
2.43.0
reply other threads:[~2026-11-13 11:01 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=20261113110128.4001610-1-hdthky0@gmail.com \
--to=hdthky0@gmail.com \
--cc=cem@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-xfs@vger.kernel.org \
/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
all inboxes | Powered by JetHome®