[BUG] xfs: undersized log triggers assertion in xfs_log_mount()
From: 铮
Date: Tue Oct 27 2026 - 12:48:10 EST
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