Re: [BUG] xfs: undersized log triggers assertion in xfs_log_mount()

From: 铮

Date: Wed Oct 28 2026 - 20:45:46 EST


Hi Dave,

Thank you for the clarification, and I apologize for not checking the
relevant code more carefully before sending the report.

I'll be more thorough in my analysis before submitting future reports.

Thanks again for your time.

Best regards,
Zheng

On Thu, Oct 29, 2026 at 4:18 AM Dave Chinner <dgc@xxxxxxxxxx> wrote:
>
> On Wed, Oct 28, 2026 at 01:00:54AM +0800, 铮 wrote:
> > Hi Carlos,
> >
> > Executing the stored syzkaller testcases on Linux 7.3.0 ultimately triggers
> > an assertion in xfs_log_mount():
> >
> > XFS (loop0): AAIEEE! Log failed size checks. Abort!
> > XFS: Assertion failed: 0, file: fs/xfs/xfs_log.c, line: 597
> > kernel BUG at fs/xfs/xfs_message.c:102!
> > ...
> > xfs_log_mount+0x4e3/0x590
> > xfs_mountfs+0x10b9/0x2270
> > xfs_fs_fill_super+0x15cc/0x20b0
> > ...
> > Kernel panic - not syncing: Fatal exception
> >
> > The log size check reports 516 blocks, below the required minimum of
> > 636 blocks.
> >
> > Is this an expected assertion with my XFS debug configuration, or should
> > this malformed image be rejected without triggering a kernel BUG?
>
> A brief look at the code the error message points at answers your
> question:
>
> /*
> * Log check errors are always fatal on v5; or whenever bad
> * metadata leads to a crash.
> */
> if (xfs_has_crc(mp)) {
> xfs_crit(mp, "AAIEEE! Log failed size checks. Abort!");
> >>>>>> ASSERT(0);
> error = -EINVAL;
> goto out_free_log;
> }
> xfs_crit(mp, "Log size out of supported range.");
> xfs_crit(mp,
> "Continuing onwards, but if log hangs are experienced then please report this message in the bug report.");
>
>
> If you turn off CONFIG_XFS_DEBUG=y, then what happens to that
> ASSERT(0)?
>
> That's right, the ASSERT(0) goes away, and then an undersized log
> causes the mount to fail with -EINVAL as it should.
>
> > I am reporting an observable assertion from a syzkaller reproduction. I am
> > not claiming a new vulnerability or a specific root cause.
>
> Please do a cursory code inspection next time, because the code
> often makes it pretty clear what the answer to your question is....
>
> -Dave.
>
> --
> Dave Chinner
> dgc@xxxxxxxxxx