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