From: Carlos Maiolino <cem@kernel.org>
To: Hongling Zeng <zenghongling@kylinos.cn>
Cc: darrick.wong@oracle.com, chandanrlinux@gmail.com,
linux-xfs@vger.kernel.org, linux-kernel@vger.kernel.org,
zhongling0719@126.com, stable@vger.kernel.org
Subject: Re: [PATCH] xfs: fix array bounds checking in log recovery
Date: Tue, 1 Sep 2026 09:06:47 +0200 [thread overview]
Message-ID: <apZ5UptiKsVGgPHZ@andromeda.toxiclabs.cc> (raw)
In-Reply-To: <20260824094535.219503-1-zenghongling@kylinos.cn>
On Mon, Aug 24, 2026 at 05:45:35PM +0800, Hongling Zeng wrote:
> The log recovery code increments array indices based on bits set in
> blf_data_map without verifying that the indices stay within the bounds
> of the item->ri_buf array.
>
> Since blf_data_map is from untrusted log data, a malicious log could set
> many bits while ri_total is small, causing array index overflow.
>
> This can result in an out-of-bounds access during log recovery, causing
> a kernel crash or memory corruption.
>
> This patch adds array bounds checking for ri_buf access in
> xlog_recover_do_reg_buffer() and xlog_recover_do_inode_buffer().
>
> The check in xlog_recover_do_inode_buffer() is placed right before the
> actual array access, not after incrementing the index, to avoid false
> positives when processing the last valid region.
>
> Fixes: 1094d3f12363 ("xfs: refactor log recovery buffer item dispatch for pass2 commit functions")
> Cc: stable@vger.kernel.org
> Signed-off-by: Hongling Zeng <zenghongling@kylinos.cn>
Hi,
is this a re-send? A v2? Please specify why you are sending the same
patche again. This saves a lot of time trying to understand why there
are two patches with the same subject in the list.
> ---
> fs/xfs/xfs_buf_item_recover.c | 26 ++++++++++++++++++++++++++
> 1 file changed, 26 insertions(+)
>
> diff --git a/fs/xfs/xfs_buf_item_recover.c b/fs/xfs/xfs_buf_item_recover.c
> index 57929f115055..7148716366ba 100644
> --- a/fs/xfs/xfs_buf_item_recover.c
> +++ b/fs/xfs/xfs_buf_item_recover.c
> @@ -485,6 +485,19 @@ xlog_recover_do_reg_buffer(
> break;
> nbits = xfs_contig_bits(buf_f->blf_data_map,
> buf_f->blf_map_size, bit);
> +
> + /*
> + * The bitmap can have more bits set than there are regions
> + * in ri_buf, so we must check array bounds before using the
> + * index to access ri_buf[i].
> + */
> + if (XFS_IS_CORRUPT(mp, i >= item->ri_total)) {
> + xfs_alert(mp,
> + "Buffer log item index (%d) exceeds allocated regions (%d).",
> + i, item->ri_total);
> + return -EFSCORRUPTED;
> + }
> +
> ASSERT(nbits > 0);
> ASSERT(item->ri_buf[i].iov_base != NULL);
> ASSERT(item->ri_buf[i].iov_len % XFS_BLF_CHUNK == 0);
> @@ -688,6 +701,19 @@ xlog_recover_do_inode_buffer(
> if (next_unlinked_offset < reg_buf_offset)
> continue;
>
> + /*
> + * Check array bounds here (right before accessing ri_buf)
> + * rather than after incrementing item_index. This avoids
> + * incorrectly rejecting logs when item_index reaches
> + * ri_total after processing the final valid region.
> + */
> + if (XFS_IS_CORRUPT(mp, item_index >= item->ri_total)) {
> + xfs_alert(mp,
> + "Inode buffer log item index (%d) exceeds allocated regions (%d).",
> + item_index, item->ri_total);
> + return -EFSCORRUPTED;
> + }
> +
> 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.25.1
>
>
next prev parent reply other threads:[~2026-09-01 7:06 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-24 9:45 [PATCH] xfs: fix array bounds checking in log recovery Hongling Zeng
2026-09-01 7:06 ` Carlos Maiolino [this message]
2026-09-01 9:39 ` Hongling Zeng
2026-09-01 9:49 ` Carlos Maiolino
2026-09-01 9:57 ` Hongling Zeng
-- strict thread matches above, loose matches on Subject: below --
2026-08-18 7:11 Hongling Zeng
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=apZ5UptiKsVGgPHZ@andromeda.toxiclabs.cc \
--to=cem@kernel.org \
--cc=chandanrlinux@gmail.com \
--cc=darrick.wong@oracle.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-xfs@vger.kernel.org \
--cc=stable@vger.kernel.org \
--cc=zenghongling@kylinos.cn \
--cc=zhongling0719@126.com \
/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.