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

[Carlos Maiolino <cem@kernel.org>]

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