All of lore.kernel.org
 help / color / mirror / Atom feed
From: Brian Foster <bfoster@redhat.com>
To: Christoph Hellwig <hch@lst.de>
Cc: Chandan Babu R <chandan.babu@oracle.com>,
	"Darrick J. Wong" <djwong@kernel.org>,
	Dave Chinner <david@fromorbit.com>,
	Sam Sun <samsun1006219@gmail.com>,
	linux-xfs@vger.kernel.org
Subject: Re: [PATCH 1/3] xfs: fix log recovery buffer allocation for the legacy h_size fixup
Date: Mon, 29 Apr 2024 08:18:23 -0400	[thread overview]
Message-ID: <Zi-QD8IdNCFHOyu7@bfoster> (raw)
In-Reply-To: <20240429070200.1586537-2-hch@lst.de>

On Mon, Apr 29, 2024 at 09:01:58AM +0200, Christoph Hellwig wrote:
> Commit a70f9fe52daa ("xfs: detect and handle invalid iclog size set by
> mkfs") added a fixup for incorrect h_size values used for the initial
> umount record in old xfsprogs versions.  But it is not using this fixed
> up value to size the log recovery buffer, which can lead to an out of
> bounds access when the incorrect h_size does not come from the old mkfs
> tool, but a fuzzer.
> 
> Fix this by open coding xlog_logrec_hblks and taking the fixed h_size
> into account for this calculation.
> 
> Fixes: a70f9fe52daa ("xfs: detect and handle invalid iclog size set by mkfs")
> Reported-by: Sam Sun <samsun1006219@gmail.com>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> ---

The commit log/fixes tag are incorrect... xlog_logrec_hblks() didn't
exist at the time a70f9fe52daa was committed. I suspect this broke later
in commit 0c771b99d6c9 ("xfs: clean up calculation of LR header
blocks"), but please double check.

Otherwise the code changes look fine to me, so with the commit log fixed
up:

Reviewed-by: Brian Foster <bfoster@redhat.com>

>  fs/xfs/xfs_log_recover.c | 20 ++++++++++++++------
>  1 file changed, 14 insertions(+), 6 deletions(-)
> 
> diff --git a/fs/xfs/xfs_log_recover.c b/fs/xfs/xfs_log_recover.c
> index b445e8ce4a7d21..bb8957927c3c2e 100644
> --- a/fs/xfs/xfs_log_recover.c
> +++ b/fs/xfs/xfs_log_recover.c
> @@ -2999,7 +2999,7 @@ xlog_do_recovery_pass(
>  	int			error = 0, h_size, h_len;
>  	int			error2 = 0;
>  	int			bblks, split_bblks;
> -	int			hblks, split_hblks, wrapped_hblks;
> +	int			hblks = 1, split_hblks, wrapped_hblks;
>  	int			i;
>  	struct hlist_head	rhash[XLOG_RHASH_SIZE];
>  	LIST_HEAD		(buffer_list);
> @@ -3055,14 +3055,22 @@ xlog_do_recovery_pass(
>  		if (error)
>  			goto bread_err1;
>  
> -		hblks = xlog_logrec_hblks(log, rhead);
> -		if (hblks != 1) {
> -			kvfree(hbp);
> -			hbp = xlog_alloc_buffer(log, hblks);
> +		/*
> +		 * This open codes xlog_logrec_hblks so that we can reuse the
> +		 * fixed up h_size value calculated above.  Without that we'd
> +		 * still allocate the buffer based on the incorrect on-disk
> +		 * size.
> +		 */
> +		if (h_size > XLOG_HEADER_CYCLE_SIZE &&
> +		    (rhead->h_version & cpu_to_be32(XLOG_VERSION_2))) {
> +			hblks = DIV_ROUND_UP(h_size, XLOG_HEADER_CYCLE_SIZE);
> +			if (hblks > 1) {
> +				kvfree(hbp);
> +				hbp = xlog_alloc_buffer(log, hblks);
> +			}
>  		}
>  	} else {
>  		ASSERT(log->l_sectBBsize == 1);
> -		hblks = 1;
>  		hbp = xlog_alloc_buffer(log, 1);
>  		h_size = XLOG_BIG_RECORD_BSIZE;
>  	}
> -- 
> 2.39.2
> 
> 


  reply	other threads:[~2024-04-29 12:16 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-04-29  7:01 fix h_size validation Christoph Hellwig
2024-04-29  7:01 ` [PATCH 1/3] xfs: fix log recovery buffer allocation for the legacy h_size fixup Christoph Hellwig
2024-04-29 12:18   ` Brian Foster [this message]
2024-04-29 17:13     ` Christoph Hellwig
2024-04-29 15:53   ` Darrick J. Wong
2024-04-29  7:01 ` [PATCH 2/3] xfs: restrict the h_size fixup in xlog_do_recovery_pass Christoph Hellwig
2024-04-29 12:18   ` Brian Foster
2024-04-29 17:15     ` Christoph Hellwig
2024-04-30 10:59       ` Brian Foster
2024-05-10 12:34         ` Brian Foster
2024-04-29 15:55   ` Darrick J. Wong
2024-04-29  7:02 ` [PATCH 3/3] xfs: clean up buffer allocation " Christoph Hellwig
2024-04-29 12:18   ` Brian Foster
2024-04-29 15:56   ` Darrick J. Wong

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=Zi-QD8IdNCFHOyu7@bfoster \
    --to=bfoster@redhat.com \
    --cc=chandan.babu@oracle.com \
    --cc=david@fromorbit.com \
    --cc=djwong@kernel.org \
    --cc=hch@lst.de \
    --cc=linux-xfs@vger.kernel.org \
    --cc=samsun1006219@gmail.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.