Re: [PATCH] xfs: validate buffer log item before reordering

[Weiming Shi]

Dave Chinner <dgc@xxxxxxxxxx> 于2026年9月14日周一 07:49写道：
>
> On Sun, Sep 13, 2026 at 07:45:30PM +0800, Weiming Shi wrote:
> > 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: co+af981e62f5c7171a@xxxxxxx
> > Closes: https://lore.kernel.org/all/aqZALi7GdVprcNOh@xxxxxxxxxxxxxxxxxxx/
> > Cc: stable@xxxxxxxxxxxxxxx
> > Assisted-by: Codex:gpt-5
> > Signed-off-by: Weiming Shi <bestswngs@xxxxxxxxx>
>
> 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
> dgc@xxxxxxxxxx

You’re right. I’m sorry that I overlooked the ongoing effort to
address these journal corruption issues systematically and instead
started from the bugs.sh patch, which merely stops this particular
crash rather than addressing the underlying problem properly.

I did analyze the crash, test the patch, and check that it handled
this reproducer; I did not send it without review or testing. However,
I understand that this does not make it a good-quality or appropriate
fix, and I’m sorry for submitting it.

I’ll follow your log-verification work and would be happy to test
whether it also addresses this issue.

Thanks,