fs/xfs: out-of-bounds in xlog_recover_buf_reorder()
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:
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:
== 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 [email protected]
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
Thank you for the report... A few suggestions below:
Quoted 8 lines
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:
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.
Quoted 1 line
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.
Quoted 11 lines
Happy to test patches. Complaints and suggestions about our work are welcome at:
== 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
Quoted 30 lines
== 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 ffff88800beee380which belongs to the cache kmalloc-8 of size 8 The buggy address is located 0 bytes to the right of
Quoted 35 lines · Carlos Maiolino
Thank you for the report... A few suggestions below:
Quoted 8 lines
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:
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.
Quoted 1 line
report.md https://bugs.sh/b/af981e62f5c7171a/report.mdIf 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.
Quoted 11 lines
Happy to test patches. Complaints and suggestions about our work are welcome at:
== 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
Quoted 7 lines
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
Quoted 33 lines
Carlos
Quoted 30 lines
== 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 ffff88800beee380which belongs to the cache kmalloc-8 of size 8 The buggy address is located 0 bytes to the right of
Quoted 35 lines · Carlos Maiolino
Thank you for the report... A few suggestions below:
Quoted 8 lines
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:
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.
Quoted 1 line
report.md https://bugs.sh/b/af981e62f5c7171a/report.mdIf 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.
Quoted 11 lines
Happy to test patches. Complaints and suggestions about our work are welcome at:
== 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
Quoted 7 lines
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
Quoted 33 lines
Carlos
Quoted 30 lines
== 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 ffff88800beee380which belongs to the cache kmalloc-8 of size 8 The buggy address is located 0 bytes to the right of
Quoted 9 lines · 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.
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
Quoted 77 lines
== Notes ===============================================================
If you fix this bug, this tag credits the report and lets us close it on our side:Reported-by [email protected]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.mdHappy to test patches. Complaints and suggestions about our work are welcome at:
== 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 ffff88800beee380which 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 [email protected]
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