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

From: Yousef Alhouseen

Date: Tue Jun 30 2026 - 06:05:56 EST


Agreed. Log block zero is valid, so using it as the sentinel is unsafe
for exactly that wrapped-log case.

I'll send v2 initializing first_bad to XFS_BUF_DADDR_NULL and checking
explicitly against that sentinel before entering the torn-write
recovery path.

Thanks,
Yousef

On Mon, 29 Jun 2026 13:13:50 -0700, "Darrick J. Wong" <djwong@xxxxxxxxxx> wrote:
> 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@xxxxxxxxxxxxxxxxxxxxxxxxx
> > Closes: https://syzkaller.appspot.com/bug?extid=b7dfbed0c6c2b5e9fd34
> > Cc: stable@xxxxxxxxxxxxxxx
> > Signed-off-by: Yousef Alhouseen <alhouseenyousef@xxxxxxxxx>
> > ---
> > 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
> >
> >