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 10:35:03PM -0400, Theodore Tso wrote:
> On Thu, Oct 29, 2026 at 10:34:44AM -0500, Dave Chinner wrote:
> > 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.
> 
> Well, there are people/companies who might be silly/stupid enough to
> think that containers are a real security isolation layer[1], and who
> think that they can let random users mount untrusted file systems in a
> container, and not have to worry about one company gaining access to
> PII belonging to another company because both companies are using a
> particular cloud hosting provider which uses containers and allows
> their customers to mount file systems as (container) root, with
> multiple customers sharing the some physical host.

As long as they use a filesystem that is proven to be safe for
untrusted user mounts, I have no problems with that model...

> As Dave has said, *all* of the file system maintainers have explicitly
> disclaimed this security model; from our perspective the block device
> is inside the trusted computing base (TCB),

Right, kernel-implemented block device based filesystems ain't those
filesystem...

> and if someone wants to
> dedicaste one or more full-time engineers to be file system developers
> who have contributed a large number of improvements to the file
> system, and who understand the context that they can competently drive
> LLM's to create architecturally sound patches,

You mean like I've been doing for XFS journal structure verification
that I've already pointed to in this thread? i.e. this patchset:

https://lore.kernel.org/linux-xfs/20261013060204.3138690-1-dgc@kernel.org/

is almost entirely LLM generated code that I've directed and
reviewed. I'm just about ready to post the second version, of which
the only external reviews I've got are from an LLM (sashiko). 

So, yeah, I'm already capable of using LLMs to write complex XFS
code, and to write it -fast-. With this level of complexity, I'm
generally only seeing LLMs review the code (i.e. sashiko). None of
the work I've done like this has had a human actually provide review
comments.

If no humans have the time/bandwidth to review what are increasingly
necessary changes (e.g. to stem the flow of shitty LLM fuzzer
generated bug fixes), then we've got a major problem with our merge
processes....

> I *might* be willing to
> change my stance for ext4.  But those hosting providers' engineers
> would have do most of the work to try to make this security model work
> --- and it might be that using fuse2fs, and running that fuse server
> in a sandbox (e.g. seccomp-bpf, etc.) might be a much simpler /
> cheaper solution in the end.

Yeah, I think that for untrusted filesystem images, the only sane
solution is to get them out of the kernel altogether.

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