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

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

[co]

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@bugs.sh

    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@bugs.sh

== 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@bugs.sh

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

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

[Carlos Maiolino]

Thank you for the report... A few suggestions below:

>     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

If you have a suggested patch, include it inlined in the message, do not
expect somebody to go and click on some random link sent to the mailing
list.


>         report.md   https://bugs.sh/b/af981e62f5c7171a/report.md

If you have no capacity to review your generated AI reports, then don't
send them to the list, we are not your AI-slop moderators/reviewers.
Neither your lab rats.

> 
>     Happy to test patches. Complaints and suggestions about our work
>     are welcome at:
> 
>         cedalion@bugs.sh
> 
> == 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

Again, same as above. Include everything in the email, do not expect
people to go and keep clicking on random links to access whatever
information you provided.
A reproducer is appreciated, but it should be in the email message not
at some random URL. This is not safe and is a security risk for
maintainers and developers to just go and click on random links.

Carlos

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

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

[CO]

On Sat, Sep 12, 2026 at 11:28 PM Carlos Maiolino <cem@kernel.org> wrote:
>
> Thank you for the report... A few suggestions below:
>
> >     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
>
> If you have a suggested patch, include it inlined in the message, do not
> expect somebody to go and click on some random link sent to the mailing
> list.
>
>
> >         report.md   https://bugs.sh/b/af981e62f5c7171a/report.md
>
> If you have no capacity to review your generated AI reports, then don't
> send them to the list, we are not your AI-slop moderators/reviewers.
> Neither your lab rats.
>
> >
> >     Happy to test patches. Complaints and suggestions about our work
> >     are welcome at:
> >
> >         cedalion@bugs.sh
> >
> > == 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
>
> Again, same as above. Include everything in the email, do not expect
> people to go and keep clicking on random links to access whatever
> information you provided.
> A reproducer is appreciated, but it should be in the email message not
> at some random URL. This is not safe and is a security risk for
> maintainers and developers to just go and click on random links.
>
Thanks so much for these comments. They are valuable to us!
(We didn't realize including links in the email raises security concerns)

We'll make bug reports:
1. External-link-free
2. No AI-generated analysis
3. The patch would be inlined at the end of the report, and we'll
state the patch's limitations clearly.

Best,
Xiang


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

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@bugs.sh
> 
>     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@bugs.sh
> 
> == 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@bugs.sh
> 
> 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
> 
> 
>