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

["Theodore Tso" <tytso@mit.edu>]

> > >  - 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.

						- Ted