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

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

[铮]

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?

I am reporting an observable assertion from a syzkaller reproduction. I am
not claiming a new vulnerability or a specific root cause.

Environment
-----------
- Kernel: 7.3.0-kernsight-kasan #1 SMP PREEMPT_DYNAMIC (2026-10-20),
  x86_64, KASAN/KCOV. Source: mainline Linux v7.3, commit
  091b06388b117fefdcb63336ac09956a4914b961, release tarball sha256
  87363c24f10e06321eb362765521094e94471f6bff8bce2d6b3e40f39f004953.
- XFS config: CONFIG_XFS_DEBUG=y, CONFIG_XFS_DEBUG_EXPENSIVE=y,
  CONFIG_XFS_ASSERT_FATAL=y. The full configuration is available as
  kernel/kernel-7.3.config in the repository.
- Kernel source changes: none for XFS or the VFS. The KernSight changes are
  in the syzkaller tree, not in the kernel.
- Taint: Not tainted (the report above is from a clean boot).
- Guest: QEMU 6.2.0, 4 vCPU, 6 GiB, KVM, x86_64; a fresh VM per run.
- Syzkaller: revision 853b104bb454141a5b0fc0e4218ec78e9f34ffb1+
  (2026-09-18). The "+" denotes local KernSight integration (seed ordering/
  state feedback: pkg/kernsight, prog/kernsight_*, syz-manager/kernsight_*,
  pkg/execbackend, vm/qemu snapshot support). It does not change the XFS
  syscall descriptions or the executor's fault-injection semantics.
- Full kernel command line:
  7.3/cmdline-7.3-20261024.txt in the repository.
- An additional fresh-VM validation on 2026-10-28 confirmed that
  repro.kernsight.prog alone triggers the assertion using the command
  below. The kernel BUG occurred at approximately 162.26 seconds after
  boot.

Reproduction
------------
The trigger is the state-construction recipe alone
(`repro.kernsight.prog`, ~2.6 MB); the smaller `repro.prog` (~24 KB) is not
needed. There is no standalone XFS image file; the image data is embedded in
the recipe. Run it on a fresh VM:

  scp syz-execprog syz-executor repro/repro.kernsight.prog root@guest:/tmp/
  ssh root@guest
  cd /tmp && chmod +x syz-execprog syz-executor
  ./syz-execprog -procs=1 -repeat=1 -disable=swap -executor
./syz-executor ./repro.kernsight.prog

Earlier observation on 7.3.0 (2026-10-24)
----------------------------------------
```
[ 155.506948][T11067] XFS (loop0): AAIEEE! Log failed size checks. Abort!
[ 155.506958][T11067] XFS: Assertion failed: 0, file:
fs/xfs/xfs_log.c, line: 597
[ 155.507283][T11067] ------------[ cut here ]------------
[ 155.507292][T11067] kernel BUG at fs/xfs/xfs_message.c:102!
[ 155.507311][T11067] Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI
[ 155.513319][T11067] CPU: 2 UID: 0 PID: 11067 Comm: syz.0.50 Not
tainted 7.3.0-kernsight-kasan #1 PREEMPT(full)
[ 155.515662][T11067] RIP: 0010:assfail+0xa2/0xb0
[ 155.527881][T11067] Call Trace:
[ 155.528122][T11067]  xfs_log_mount+0x4e3/0x590
[ 155.528503][T11067]  xfs_mountfs+0x10b9/0x2270
[ 155.530595][T11067]  xfs_fs_fill_super+0x15cc/0x20b0
[ 155.531014][T11067]  get_tree_bdev_flags+0x38e/0x620
[ 155.553843][T11067] Kernel panic - not syncing: Fatal exception
```

Questions
---------
- Is triggering a fatal assertion for an undersized V5 log intentional
  with CONFIG_XFS_DEBUG=y and CONFIG_XFS_ASSERT_FATAL=y, or should this
  case return -EINVAL without triggering a BUG?
- If a diagnostic dump would help, what state should be printed before the
  assertion so the malformed image/log geometry can be identified?

Materials
---------
The full testcases, 7.3.0 serial/console logs, crash report, .config and
reproduction script are in the public repository:

  https://github.com/Zheng-zheng-codes/e713403e-xfs-assfail-repro

Contents include:
  repro/repro.kernsight.prog             state-construction recipe (~2.6 MB)
  repro/repro.prog                       small testcase (~24 KB; NOT needed)
  7.3/validation-run-20261028/          2026-10-28 recipe-only validation
                                         (serial log, boot information,
                                         kernel command line)
  7.3/serial-7.3-20261024.log            full boot-to-crash serial log
  7.3/crash-excerpt-7.3-20261024.txt     extracted crash report
  7.3/console-7.3-20261024.log
  7.3/cmdline-7.3-20261024.txt
  7.3/boot-info-7.3-20261024.txt
  7.3/RESULT.txt                          earlier 2026-10-24 harness result
                                         (its 466 s is the old harness duration,
                                         not the 162.26 s crash time above)
  kernel/kernel-7.3.config, kernel/SOURCES.md
  reproduce.sh, verify.sh, MANIFEST.sha256

Best regards,
Zheng Zheng

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

[Carlos Maiolino]

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?

You have bug_on_assert set on your system, so yes, this is intended. If
you don't want to panic() the machine there, you need to disable it on
sysfs, but...

> Questions
> ---------
> - Is triggering a fatal assertion for an undersized V5 log intentional
>   with CONFIG_XFS_DEBUG=y and CONFIG_XFS_ASSERT_FATAL=y, or should this
>   case return -EINVAL without triggering a BUG?

The config you have enable explicitly says asserts are fatal. I'm not
sure if I misunderstood you or you misunderstood the configuration
option.


> - If a diagnostic dump would help, what state should be printed before the
>   assertion so the malformed image/log geometry can be identified?

You are running a kernel configured with debug configuration that are
meant to crash the system when some issue is found. Those are
configuration settings used for development and debug purposes, not to
use on a production or semi-production system.

Cheers,
Carlos

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

[铮]

Hi Carlos,

Replaying the syzkaller recipe linked below triggers an assertion in
xfs_log_mount(). 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?

I am reporting an observable assertion with a deliberately malformed XFS
image. I am not claiming a new vulnerability or a specific root cause.

Environment
-----------
- Kernel used for the actual reproduction: 7.3.0-kernsight-kasan #1 SMP
  PREEMPT_DYNAMIC, x86_64, KASAN/KCOV. Source: mainline Linux v7.3, commit
  091b06388b117fefdcb63336ac09956a4914b961 (release tarball sha256
  87363c24f10e06321eb362765521094e94471f6bff8bce2d6b3e40f39f004953).
- Original report: 7.1.3-kernsight-kasan #13, commit
  113be0295f4f632d61f4e9c93322f70e2365f54d (the tree is not a git checkout).
- Also reproduced on 7.2.11-kernsight-kasan, commit
  8316c24ec1b77dba19ba072ca4fe251b36dc65d3.
- XFS config (7.3.0): CONFIG_XFS_DEBUG=y, CONFIG_XFS_DEBUG_EXPENSIVE=y,
  CONFIG_XFS_ASSERT_FATAL=y. The 7.2.11 config has CONFIG_XFS_DEBUG=y and
  CONFIG_XFS_ASSERT_FATAL=y. The three .config files are in the repository.
- Kernel source changes: none for XFS or the VFS in any of the three trees.
  The KernSight changes are in the syzkaller tree, not in the kernel.
- Out-of-tree modules: the original 7.1.3 log was captured in a guest with
  the out-of-tree module ltp_tpci loaded (taint O/E). The 7.3.0 log used for
  this report does not contain ltp_tpci and is clean on that point; a 7.1.3
  re-validation without ltp_tpci has not been done.
- Guest: QEMU 6.2.0, 4 vCPU, 6 GiB, KVM, x86_64; a fresh VM per run.
- Syzkaller: revision 853b104bb454141a5b0fc0e4218ec78e9f34ffb1+
  (2026-09-18); "+" denotes local KernSight integration (seed ordering/state
  feedback in pkg/kernsight, prog/kernsight_*, syz-manager/kernsight_*,
  pkg/execbackend, vm/qemu snapshot support). It does not change the XFS
  syscall descriptions or the executor's fault-injection semantics.
- Kernel command line: root=/dev/sda console=ttyS0 fstab=no rw
  earlyprintk=serial net.ifnames=0 oops=panic panic_on_warn=1
  panic=86400 hung_task_panic=1 softlockup_panic=1 nmi_watchdog=panic
  sysctl.kernel.hung_task_all_cpu_backtrace=1
  sysctl.kernel.panic_on_rcu_stall=1
  sysctl.kernel.max_rcu_stall_to_panic=1 rcupdate.rcu_expedited=1
  rcupdate.rcu_cpu_stall_cputime=1 no_hash_pointers page_owner=on
  sysctl.vm.nr_hugepages=4 sysctl.vm.nr_overcommit_hugepages=4
  secretmem.enable=1 msr.allow_writes=off coredump_filter=0xffff
  vsyscall=native kvm-intel.nested=1 spec_store_bypass_disable=prctl
  nopcid vivid.n_devs=64
vivid.multiplanar=1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2
  netrom.nr_ndevs=32 rose.rose_ndevs=32 smp.csd_lock_timeout=100000
  watchdog_thresh=55 workqueue.watchdog_thresh=140
  sysctl.net.core.netdev_unregister_timeout_secs=140 dummy_hcd.num=16
  max_loop=32 nbd.nbds_max=32 comedi.comedi_num_legacy_minors=4
  kunit.autorun=0 vcan.echo=1
- Reproduction counts (methods kept separate): full 37-program recipe on
  7.3.0: 1/1; standalone mount-32.prog on 7.3.0: 1/1; 7.2.11 state-primed:
  1/1; 7.1.3: original report. A repeated cold-boot run (e.g. 5/5) and a
  non-debug / CONFIG_XFS_ASSERT_FATAL=n kernel were not tested.

Reproduction
------------
The independent trigger is `xfs-mounts/mount-32.prog`, a single
`syz_mount_image$xfs` program extracted from the full recipe. Run it alone in
a fresh 7.3.0 VM with the same execprog arguments:

  scp syz-execprog syz-executor mount-32.prog root@guest:/tmp/
  ssh root@guest
  cd /tmp && chmod +x syz-execprog syz-executor
  ./syz-execprog -procs=1 -repeat=1 -disable=swap -executor
./syz-executor ./mount-32.prog

Its serial log shows the same failure (516 < 636 blocks,
`fs/xfs/xfs_log.c:597`, kernel BUG, panic); it is archived as
`xfs-mounts/results/mount-32/serial.log`. The full 37-program recipe
(`repro/repro.kernsight.prog`) also triggers it. The other 9 extracted mount
blocks did not show the crash in their captured serial logs. The programs,
commands and per-run logs are in `xfs-mounts/` (`xfs-mounts/RESULTS.md`).
Note that syz-execprog's `executed programs: 0` / `EXIT:0` lines are not
proof of execution; the serial logs are the evidence. No preceding recipe
replay was needed in this standalone run. Further minimisation of
`mount-32.prog` has not been attempted. `repro/repro.prog` is only the
tty/KDSKBSENT testcase and is not the XFS trigger.

Observed on 7.3.0
-----------------
During the full-recipe run, at 155.287 s:

  [ 155.287055][T11019] XFS (loop0): Log size 516 blocks too small,
minimum size is 636 blocks
  [ 155.287075][T11019] XFS: Assertion failed: 0, file:
fs/xfs/xfs_log.c, line: 597
  [ 155.287882][T11019] kernel BUG at fs/xfs/xfs_message.c:102!
  [ 155.295065][T11019] RIP: 0010:assfail+0xa2/0xb0
  [ 155.304491][T11019]  xfs_log_mount+0x4e3/0x590
  [ 155.320739][T11019] RIP: 0010:assfail+0xa2/0xb0
  [ 155.320891][T11019] Kernel panic - not syncing: Fatal exception

In the standalone mount-32 run, at 259.143/259.154 s:

  [ 259.143249][T10455] XFS (loop0): Mounting V5 Filesystem
a2f82aab-77f8-4286-afd4-a8f747a74bab
  [ 259.154708][T10455] XFS (loop0): Log size 516 blocks too small,
minimum size is 636 blocks
  [ 259.154745][T10455] XFS: Assertion failed: 0, file:
fs/xfs/xfs_log.c, line: 597
  [ 259.155220][T10455] kernel BUG at fs/xfs/xfs_message.c:102!
  [ 259.193047][T10455] Kernel panic - not syncing: Fatal exception

The original 7.1.3 report shows the same log-size diagnostic and
assertion at fs/xfs/xfs_log.c:593:

  XFS (loop1): Log size 516 blocks too small, minimum size is 636 blocks
  XFS: Assertion failed: 0, file: fs/xfs/xfs_log.c, line: 593
  kernel BUG at fs/xfs/xfs_message.c:102!
  RIP: 0010:assfail fs/xfs/xfs_message.c:102 [inline]
  xfs_log_mount+0x4e3/0x590 fs/xfs/xfs_log.c:593

On 7.2.11 the state-primed replay reproduces the same crash
(2026-10-20T09:15:38Z, C=false); the report excerpt is in the repository.

Questions
---------
- Is this assertion expected when mounting an image whose log is smaller
  than the minimum, or should xfs_log_mount() reject the image without
  triggering a kernel BUG?
- Is the XFS (loop0) "Log size ... too small" path intended to be fatal
  under CONFIG_XFS_DEBUG + CONFIG_XFS_ASSERT_FATAL, or is it a case that
  should be handled gracefully regardless of the debug configuration?

Materials
---------
The full programs, embedded image, .config files and boot-to-crash serial
logs are available at:

  https://github.com/Zheng-zheng-codes/xfs-undersized-log-assert-repro

Contents:
  repro/repro.prog                tty/KDSKBSENT testcase (NOT the XFS trigger)
  repro/repro.kernsight.prog      full 37-program recipe; contains the
XFS image/mounts
  7.1.3/report0, 7.1.3/log0       original 7.1.3 report and full log
  7.1.3/machineInfo0, 7.1.3/description, 7.1.3/pre_state0
  7.2.11/RESULT.md, 7.2.11/repro.*   7.2.11 state-primed reproduction
  7.3/serial-7.3.log              full 7.3.0 boot-to-crash serial log
  7.3/console-7.3.log, 7.3/cmdline-7.3.txt,
  7.3/boot-info-7.3.txt, 7.3/RESULT-7.3.txt
  xfs-mounts/                     10 extracted mount blocks + standalone results
  kernel/kernel-7.1.3.config, kernel/kernel-7.2.11.config,
  kernel/kernel-7.3.config, kernel/SOURCES.md

Best regards,
Zheng Zheng