All of lore.kernel.org
 help / color / mirror / Atom feed
From: Hongling Zeng <zhongling0719@126.com>
To: Carlos Maiolino <cem@kernel.org>
Cc: Hongling Zeng <zenghongling@kylinos.cn>,
	darrick.wong@oracle.com,  chandanrlinux@gmail.com,
	linux-xfs@vger.kernel.org,  linux-kernel@vger.kernel.org,
	stable@vger.kernel.org
Subject: Re: [PATCH] xfs: fix array bounds checking in log recovery
Date: Tue, 01 Sep 2026 17:57:09 +0800	[thread overview]
Message-ID: <6A96A175.1090700@126.com> (raw)
In-Reply-To: <apafftcOk6XIDYTQ@andromeda.toxiclabs.cc>


在 2026年09月01日 17:49, Carlos Maiolino 写道:
> On Tue, Sep 01, 2026 at 05:39:57PM +0800, Hongling Zeng wrote:
>> 在 2026年09月01日 15:06, Carlos Maiolino 写道:
>>> 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.
>> Hi ,
>> This is the same patch version, but the previous submission failed to
>> apply because my local repository was out of date. I updated my tree and
>> resubmitted the patch with the same fix.
>>
>> Sorry for the confusion.
> So this is not the same version, it's a rebase against top of the tree
> and that should be properly described.
>
> I'll be updating for-next soon this week, please rebase it again on top
> of for-next once I publish it and re-send it.
>
> Cheers,
> Carlos
> |
> |
|Thanks for the clarification.

Got it — this is a rebase, not a new version. I’ll wait for your updated
for-next tree, rebase the fix on top of it, and resend it with an
appropriate changelog.

Sorry for the confusion.

Thanks,
Hongling|
>> Thanks,
>> Hongling
>>>> ---
>>>>    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
>>>>
>>>>
>>


  reply	other threads:[~2026-09-01  9:58 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
2026-09-01  9:39   ` Hongling Zeng
2026-09-01  9:49     ` Carlos Maiolino
2026-09-01  9:57       ` Hongling Zeng [this message]
  -- 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=6A96A175.1090700@126.com \
    --to=zhongling0719@126.com \
    --cc=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 \
    /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.