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@xxxxxxxxxx> 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@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
>
> 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
>