mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Dave Chinner <dgc@kernel.org>
To: 铮 <fengaojigui88@gmail.com>
Cc: cem@kernel.org, linux-xfs@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [BUG] xfs: undersized log triggers assertion in xfs_log_mount()
Date: Thu, 29 Oct 2026 07:18:34 +1100	[thread overview]
Message-ID: <auJYmq07gDhTkJfe@dread> (raw)
In-Reply-To: <CAO-4RZ25PZ5BM+83Vk8t5NUY3ksLGz5nzONrncipu2_MZhFSsg@mail.gmail.com>

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

  parent reply	other threads:[~2026-10-28 20:18 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-27 17:00 铮
2026-10-27 17:32 ` Carlos Maiolino
2026-10-28  0:39   ` 铮
2026-10-28 20:18 ` Dave Chinner [this message]
2026-10-29  0:45   ` 铮
  -- strict thread matches above, loose matches on Subject: below --
2026-10-27 16:35 铮

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=auJYmq07gDhTkJfe@dread \
    --to=dgc@kernel.org \
    --cc=cem@kernel.org \
    --cc=fengaojigui88@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-xfs@vger.kernel.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®