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

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

[Yousef Alhouseen]

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;
 	xfs_daddr_t		tmp_rhead_blk;
 	int			found;
 	int			error;
-- 
2.54.0

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

[Darrick J. Wong]

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
> 
> 

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

[Yousef Alhouseen]

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@kernel.org> 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@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
> >
> >