Re: [PATCH] xfs: initialize first bad log block in head verification

["Darrick J. Wong" <djwong@kernel.org>]

On Sun, Jun 28, 2026 at 11:25:13AM +0200, Yousef Alhouseen wrote:
> xlog_do_recovery_pass() only writes first_bad when it reaches the common
> error exit after processing a log record. An earlier CRC or corruption
> failure can therefore return without initializing the out-parameter.
> 
> xlog_verify_head() tests first_bad on those errors and may then use its
> uninitialized stack value as a log block number while searching for the
> last good record. Initialize it to zero, matching xlog_verify_tail(), so
> an error without a recorded bad block is returned directly.
> 
> Fixes: 7088c4136fa1 ("xfs: detect and trim torn writes during log recovery")
> Reported-by: syzbot+b7dfbed0c6c2b5e9fd34@syzkaller.appspotmail.com
> Closes: https://syzkaller.appspot.com/bug?extid=b7dfbed0c6c2b5e9fd34
> Cc: stable@vger.kernel.org
> Signed-off-by: Yousef Alhouseen <alhouseenyousef@gmail.com>
> ---
>  fs/xfs/xfs_log_recover.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/fs/xfs/xfs_log_recover.c b/fs/xfs/xfs_log_recover.c
> index 09e6678ca487..d8125f3add4b 100644
> --- a/fs/xfs/xfs_log_recover.c
> +++ b/fs/xfs/xfs_log_recover.c
> @@ -1028,7 +1028,7 @@ xlog_verify_head(
>  {
>  	struct xlog_rec_header	*tmp_rhead;
>  	char			*tmp_buffer;
> -	xfs_daddr_t		first_bad;
> +	xfs_daddr_t		first_bad = 0;

Why is it safe to set this to the first daddr of the log?  Is it
possible that a filesystem could have a log record starting near the end
of the log which wrapped around, and later suffered a CRC corruption in
daddr 0?

xfs_daddr_t already defines an explicit null value (XFS_BUF_DADDR_NULL);
wouldn't it be /much/ safer to set that here and update the if test body
later?

--D

>  	xfs_daddr_t		tmp_rhead_blk;
>  	int			found;
>  	int			error;
> -- 
> 2.54.0
> 
>