From: Weiming Shi <bestswngs@gmail.com>
To: Carlos Maiolino <cem@kernel.org>
Cc: linux-xfs@vger.kernel.org, linux-kernel@vger.kernel.org,
Kyle Zeng <kylebot@openai.com>, Xiang Mei <xmei5@asu.edu>,
Brian Foster <bfoster@redhat.com>,
stable@vger.kernel.org
Subject: [PATCH] xfs: bound inode buffer log item replay by logged regions
Date: Wed, 29 Jul 2026 12:31:27 -0700 [thread overview]
Message-ID: <20260729193127.3084301-1-bestswngs@gmail.com> (raw)
xlog_recover_do_inode_buffer() advances item_index once for every run of
set bits in the logged dirty bitmap, but ri_buf[] is populated only for
the regions present in the recovered log item. A crafted inode buffer
log item can therefore make the dirty bitmap describe more runs than the
item has logged regions, and recovery reads past the end of ri_buf[]
before dereferencing the bogus iov_base pointer.
The ASSERT() that checks iov_base compiles away without CONFIG_XFS_DEBUG,
and evaluating it would already perform the out-of-bounds ri_buf[] read.
Check item_index against ri_cnt before the first ri_buf[item_index]
access instead, and fail recovery with -EFSCORRUPTED.
Found with KASAN on a CONFIG_XFS_DEBUG=n build by mounting a crafted XFS
image whose log contains an inode buffer item with more dirty bitmap runs
than logged regions:
BUG: KASAN: slab-out-of-bounds in xlog_recover_do_inode_buffer (fs/xfs/xfs_buf_item_recover.c:701)
Read of size 8 at addr ffff88801387d160 by task mount
The buggy address is located 0 bytes to the right of
allocated 32-byte region [ffff88801387d140, ffff88801387d160)
xlog_recover_do_inode_buffer (fs/xfs/xfs_buf_item_recover.c:701)
xlog_recover_buf_commit_pass2 (fs/xfs/xfs_buf_item_recover.c:1130)
...
Oops: general protection fault, probably for non-canonical address
RIP: 0010:xlog_recover_do_inode_buffer (fs/xfs/xfs_buf_item_recover.c:703)
After this change the crafted image fails recovery with -EFSCORRUPTED and
the mount is refused.
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Reported-by: Kyle Zeng <kylebot@openai.com>
Link: https://lore.kernel.org/linux-xfs/20260611212314.4610-1-kylebot@openai.com/
Reported-by: Xiang Mei <xmei5@asu.edu>
Suggested-by: Brian Foster <bfoster@redhat.com>
Link: https://lore.kernel.org/linux-xfs/ajGB9o5Ys6itU3Rh@bfoster/
Cc: stable@vger.kernel.org
Signed-off-by: Weiming Shi <bestswngs@gmail.com>
---
fs/xfs/xfs_buf_item_recover.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/fs/xfs/xfs_buf_item_recover.c b/fs/xfs/xfs_buf_item_recover.c
index 02b95b89d1b5..2c2d4a0027af 100644
--- a/fs/xfs/xfs_buf_item_recover.c
+++ b/fs/xfs/xfs_buf_item_recover.c
@@ -659,6 +659,13 @@ xlog_recover_do_inode_buffer(
reg_buf_offset = bit << XFS_BLF_SHIFT;
reg_buf_bytes = nbits << XFS_BLF_SHIFT;
item_index++;
+
+ if (XFS_IS_CORRUPT(mp, item_index >= item->ri_cnt)) {
+ xfs_alert(mp,
+ "Bad inode buffer log item dirty bitmap: more dirty regions than the %d logged, for buffer at daddr 0x%llx.",
+ item->ri_cnt - 1, xfs_buf_daddr(bp));
+ return -EFSCORRUPTED;
+ }
}
/*
@@ -669,7 +676,6 @@ xlog_recover_do_inode_buffer(
if (next_unlinked_offset < reg_buf_offset)
continue;
- ASSERT(item->ri_buf[item_index].iov_base != NULL);
ASSERT((item->ri_buf[item_index].iov_len % XFS_BLF_CHUNK) == 0);
ASSERT((reg_buf_offset + reg_buf_bytes) <= BBTOB(bp->b_length));
--
2.43.0
next reply other threads:[~2026-07-29 19:31 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-29 19:31 Weiming Shi [this message]
2026-07-30 0:06 ` [PATCH] xfs: bound inode buffer log item replay by logged regions Dave Chinner
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=20260729193127.3084301-1-bestswngs@gmail.com \
--to=bestswngs@gmail.com \
--cc=bfoster@redhat.com \
--cc=cem@kernel.org \
--cc=kylebot@openai.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-xfs@vger.kernel.org \
--cc=stable@vger.kernel.org \
--cc=xmei5@asu.edu \
/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.