Re: [PATCH] xfs: fix out-of-bounds write from crafted btree root numrecs during log recovery

[Dave Chinner <dgc@kernel.org>]

On Wed, Oct 28, 2026 at 04:43:37PM -0600, Jonathan Corbet wrote:
> Dave Chinner <dgc@kernel.org> writes:
> 
> > Unless you know how to fix the discovered problem correctly, don't
> > send what your LLM proposed for review. It will be garbage, and all
> > that will do is annoy whoever has to review it. Just report the bug,
> > let the subsystem developers fix it.
> 
> Just to be obnoxious...this runs counter to the advice we have in
> Documentation/process/security-bugs.rst, where reporters are requested
> to include a proposed fix as well.  It seems we're sending a bit of a
> mixed message...

These aren't security bugs. Bugs that result from maliciously
corrupted filesystem images (i.e. fuzzed) are explicitly stated as
not covered by the kernel security threat models. IOWs, they are
just -bugs-, and bugs that just don't ever happen in the real world.

The journal records are CRC'd and location stamped, so any sort of
real world storage error (e.g.  media corruption, misdirected write,
etc) will already be caught and rejected. Hence to get to these
issues, someone has to corrupt the journal stuctures and manually
rewrite the CRCs to get them to pass verification before we are
exposed to any of these issues.

Really, though, as someone who has learnt how to make LLMs generate
decent code, I'm disappointed in how frequently I'm to tell random
people using LLMs that their code is complete shite. LLMs don't
generate bad code when they are well directed by a human.  Bad code
is a sign of a poor coder (i.e. a human failing), regardless of
whether an LLM generated the code or not.

However, regardless of the skill and capability of the human driving
the LLM, LLMs will still generate decent bug reports. I'll take a
good bug report over bad code every day of the week.

-Dave.
-- 
Dave Chinner
dgc@kernel.org