xfs: validate buffer log item before reordering

Log recovery reorders transaction items before buffer item pass1 validates the format of region 0. A corrupt log can therefore supply a four-byte region containing only blf_type and blf_size. xlog_recover_buf_reorder() then reads blf_flags immediately past the allocation:

  BUG: KASAN: slab-out-of-bounds in xlog_recover_buf_reorder
  Read of size 2 at addr ffff88800e40e364 by task poc/133
  Call Trace:
   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
  The buggy address is located 0 bytes to the right of
  allocated 4-byte region [ffff88800e40e360, ffff88800e40e364)

Validate region 0 before inspecting the flags. Keep a malformed item on the regular item list so that xlog_recover_buf_commit_pass1() reports the corrupt log through the existing error path.

Fixes 86ffa471d9ce ("xfs: refactor log recovery item sorting into a generic dispatch structure")

Reported-by [email protected]

Closes https://lore.kernel.org/all/[email protected]/ open here

Cc [email protected]

Assisted-by Codex:gpt-5

Signed-off-by Weiming Shi <[email protected]>

Quoted 27 lines · Weiming Shi

Log recovery reorders transaction items before buffer item pass1 validates the format of region 0. A corrupt log can therefore supply a four-byte region containing only blf_type and blf_size. xlog_recover_buf_reorder() then reads blf_flags immediately past the allocation:

  BUG: KASAN: slab-out-of-bounds in xlog_recover_buf_reorder
  Read of size 2 at addr ffff88800e40e364 by task poc/133
  Call Trace:
   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
  The buggy address is located 0 bytes to the right of
  allocated 4-byte region [ffff88800e40e360, ffff88800e40e364)

Validate region 0 before inspecting the flags. Keep a malformed item on the regular item list so that xlog_recover_buf_commit_pass1() reports the corrupt log through the existing error path.

Quoted 6 lines

Fixes 86ffa471d9ce ("xfs: refactor log recovery item sorting into a generic dispatch structure")

Reported-by [email protected]

Closes https://lore.kernel.org/all/[email protected]/ open here

Cc [email protected]

Assisted-by Codex:gpt-5

Signed-off-by Weiming Shi <[email protected]>

That's pretty poor form - taking a bug reported by someone else and then reposting their proposed fix as if it was your own before they've even had a chance to respond to the maintainer's comments.

And that's even before I take into account that the proposed fix is an extremely poor one. It basically punts the broken log item down the road where some future processing operation happens to catch it and abort journal recovery with EFSCORRUPTEDEFSCORRUPTED before bad things happen.

i.e. you didn't review it, nor did your directions to the LLM that "helped" you direct it to determine if this was the right way to fix this issue.

To compound this all, I've previously asked you directly to stop sending patches that add random verification checks to random parts of log recovery and instead spend time on actually addressing the root cause of these issues. i.e. that we lack robust on-disk format verification of the journal contents.

Last week, when someone else posted a random 'log vector is broken' hack, I said the same thing (yet again!) and posted the design doc I wrote a while back to provide robust, generic log item validation for the entire journal:

https://lore.kernel.org/linux-xfs/ap8ucHIw-pKLhh9c@dread/

I posted a link to the git repo where I've started this work further down that discussion:

| Ok, I just posted my current WIP to the log-verification-1 branch
| in my kernel.org repo
| (https://git.kernel.org/pub/scm/linux/kernel/git/dgc/linux-xfs.git)

That's the work we need to do to get rid of -all- the journal corruption issues in one go; once we have that in place then almost all corruptions will be caught long before any of the recovery parsing code can trip over it....

-Dave.
--
Dave Chinner
[email protected]