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

[Eric Sandeen]

On 9/13/26 12:56 AM, co wrote:
> 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.

A few thoughts here.

This looks very much like you have re-implemented syzkaller & syzbot,
and are following in their missteps.

A filesystem bug report with a reproducer consisting of a big binary
array in a C file is just about the least useful way to provide the
report. The first thing anyone looking at it must do is reverse-engineer
what is going on, what the inputs are, etc.
"static const unsigned char img_blob[]" is not conducive to that.

After a prolonged effort, syzbot now provides a filesystem image for
reports like these, so that standard filesystem analysis and debugging
tools can be used. At a minimum, you should do the same.

I would also suggest that if you have compute resources to spare, you
can do more than test only your targeted reproducer. We have a
comprehensive test suite available, and anyone can run it. It's a fairly
standard expectation that patches sent to the list have been well tested,
and not left as work for others to do.

But as a bigger picture, as Dave Chinner has said elsewhere on the
list recently, these sorts of fuzzer/AI guided bugs and patches are
not addressing problems holistically. They lead to lots of one-off
fixes (or band-aids) sprinkled around the code, rather than looking
at the problem in a comprehensive or systemic manner. Dave's doing work
now to validate all on-disk data used during log replay,
and it will almost certainly address the class of bug you've reported
here.

The problem we are facing more and more frequently is that it is becoming
extremely easy for just about anyone to generate bug reports. It still
falls to a small set of humans to evaluate and respond to those reports.

The more reporters can do to reduce friction and increase confidence
in the work being presented, the better.

As a final thought, given that this looks very much like syzkaller, I
would ask whether your framework does things that syzkaller cannot do.
Syzkaller is well-established and well understood, with a good framework
for tracking reports, fixes, etc. Re-inventing that is a burden on the
whole community; if you have improvements over syzkaller, folding those
back into the syzkaller project would be preferable to what looks essentially
like a fork, and asking the kernel community to now deal with an entirely
new, separate fuzzer-bug reporting and tracking framework.

Thanks,
-Eric

> == 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
> 
> 
>