[BUG] fs/xfs: out-of-bounds in xlog_recover_buf_reorder()

From: co

Date: Sun Sep 13 2026 - 01:58:00 EST


This is a bug report, not a patch submission.

We found a bug reachable in:

path fs/xfs
crash out-of-bounds in xlog_recover_buf_reorder()
commit 2709dd5ae32f ("Merge tag 'sched-urgent-2026-08-22' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip")

Config, environment, the sanitizer report and a C reproducer follow.

== Notes ===============================================================
If you fix this bug, this tag credits the report and lets us
close it on our side:

Reported-by: co+af981e62f5c7171a@xxxxxxx

Everything in this mail is validated by the reproducer below.

We also hold an unreviewed LLM-generated analysis and candidate
patch. The same reproducer panics the unpatched kernel and runs
clean with that patch applied. Use it as a starting point, or ignore
it and write your own:

patch.diff https://bugs.sh/b/af981e62f5c7171a/patch.diff
report.md https://bugs.sh/b/af981e62f5c7171a/report.md

Happy to test patches. Complaints and suggestions about our work
are welcome at:

cedalion@xxxxxxx

== Environment =========================================================
Reproduced on 2709dd5ae32f ("Merge tag 'sched-urgent-2026-08-22' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip")
VM setup https://bugs.sh/b/af981e62f5c7171a/run.sh
config https://bugs.sh/b/af981e62f5c7171a/config.gz
poc https://bugs.sh/b/af981e62f5c7171a/repro.c

== Sanitizer Report ====================================================
BUG: KASAN: slab-out-of-bounds in xlog_recover_buf_reorder (fs/xfs/xfs_buf_item_recover.c:164)
Read of size 2 at addr ffff88800beee384 by task exploit/147
Call Trace:
dump_stack_lvl (lib/dump_stack.c:94 lib/dump_stack.c:120)
print_report (mm/kasan/report.c:378 mm/kasan/report.c:482)
kasan_report (mm/kasan/report.c:595)
xlog_recover_buf_reorder (fs/xfs/xfs_buf_item_recover.c:164)
xlog_recover_reorder_trans (fs/xfs/xfs_log_recover.c:1929)
xlog_recover_commit_trans (fs/xfs/xfs_log_recover.c:2053)
xlog_recovery_process_trans (fs/xfs/xfs_log_recover.c:2319)
xlog_recover_process_data (fs/xfs/xfs_log_recover.c:2510)
xlog_do_recovery_pass (fs/xfs/xfs_log_recover.c:3253)
xlog_do_log_recovery (fs/xfs/xfs_log_recover.c:3340)
xlog_do_recover (fs/xfs/xfs_log_recover.c:3377)
xlog_recover (fs/xfs/xfs_log_recover.c:3502)
xfs_log_mount (fs/xfs/xfs_log.c:617)
xfs_mountfs (fs/xfs/xfs_mount.c:1031)
xfs_fs_fill_super (fs/xfs/xfs_super.c:1987)
get_tree_bdev_flags (fs/super.c:1887)
vfs_get_tree (fs/super.c:1947)
fc_mount (fs/namespace.c:1198)
path_mount (fs/namespace.c:3772 fs/namespace.c:3848 fs/namespace.c:4168)
__x64_sys_mount (fs/namespace.c:4181 fs/namespace.c:4397 fs/namespace.c:4374 fs/namespace.c:4374)
do_syscall_64 (arch/x86/entry/syscall_64.c:61 arch/x86/entry/syscall_64.c:84)
entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121)
The buggy address belongs to the object at ffff88800beee380
which belongs to the cache kmalloc-8 of size 8
The buggy address is located 0 bytes to the right of


---
The report format is based on syzbot bug report.

This report is generated by a bot. It may contain errors.
See https://github.com/n132/cedalion for more information.

For any issue with this report, reach out to cedalion@xxxxxxx

If the report is already addressed, let us know by replying with:
#co fix: <commit hash>

If the report is a duplicate of another one, reply with:
#co dup: <lore link>

If you want to undo deduplication, reply with:
#co undup