Re: [PATCH] docs: add guidelines for submitting new filesystems

["Darrick J. Wong" <djwong@kernel.org>]

On Wed, Apr 22, 2026 at 04:35:15PM +0200, Amir Goldstein wrote:
> On Wed, Apr 22, 2026 at 4:10 PM Theodore Tso <tytso@mit.edu> wrote:
> >
> > > > >  - Handle security issues and regression promptly.  Both those reported
> > > > >    by ordinary users and those reported by test bots and fuzzing tools.
> > > > >    The filesystem must handle corrupted input gracefully without hanging
> > > > >    or crashing the kernel.
> > > >
> > > > How about
> > > > "...without corrupting memory, hanging, or crashing the kernel."
> >
> > I will note that security@kernel.org does not consider maliciously
> > fuzzed file systems as a security issue.  And a long-standing position
> > by both ext4 and xfs has been that distributions configuring
> > automounters to blindly mount USB sticks dropped in the parking lot by
> > the KGB, MSS, or NSA is a Bad Idea.
> >
> > I'm a bit nervous about stating this as an expectation, especially
> > given denial of service attacks on maintainer time with a large number
> > of random academics which fork syzkaller, and send security reports
> > that mostly duplicate upstream syzkaller reports and don't support the
> > web site allowing developers to test syzkaller exports which don't
> > reproduce locally.
> >
> > It's certainly an ideal, but I'm not sure it's one we can expect or
> > guarantee.  It's also certainly not the case on most file systems
> > in-tree today, to a varying degrees, but outside of the most highly
> > maintained file systems, if we were to state this, (a) I'd be
> > concerned that we would be setting expectations that will disappoint
> > Linux users, or worse, class-action lawyers (well, they would be
> > rubbing their hands with glee), and (b) if we actually enforced it,
> > would probably result in 90% of the current in-tree file systems
> > getting removed.

Is that such a bad thing?  Reducing the kernel attack surface by that
much would be a blessing, because any missteps in the kernel means it's
game over for the entire running system.

It's also a blessing for anyone trying to do core code changes ala
willy's folio conversion project.

> This is a sentence that I removed and Darrick asked me to
> add it back, because "Not screwing over a running system is
> important, The guidelines ought to make that explicit."
> 
> "The filesystem must handle corrupted input gracefully
>  without corrupting memory, hanging or crashing the kernel."
> 
> Please suggest a variant which you are comfortable with and
> captures the sentiment that Darrick wished to express.

I'm willing to relax on the "not hanging" part since it /is/ difficult
to detect inter-fsblock loops, and the solution that I thought I had
found (attach xfs_bufs to empty xfs transaction, look for obvious
clues in xfs_buf) is apparently no longer viewed favorably by dchinner.

https://lore.kernel.org/linux-xfs/Zw8ulrPaeXw8bUnd@dread.disaster.area/

Implementing a full-on cycle detector in xfs_btree *would* be a fun
project for someone who really wants to dig in to btrees, however.

--D