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

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

On Mon, Apr 20, 2026 at 08:14:58PM +0200, Amir Goldstein wrote:
> On Mon, Apr 20, 2026 at 4:37 PM Jan Kara <jack@suse.cz> wrote:
> >
> > On Fri 17-04-26 16:25:03, Amir Goldstein wrote:
> > > + - Handle security issues promptly.  Filesystems parse complex on-disk
> > > +   structures from potentially untrusted media and must treat security
> > > +   reports with urgency.
> >
> > I've commented on this in reply to Matthew. I agree syzbot results must be
> > reviewed and identified security issues treated in a timely manner. However
> > dealing with maliciously corrupted on-disk data isn't (IMO) a serious
> > attack vector. Even current well maintained filesystems (e.g. ext4 and
> > others) have some issues in this area so it seems unfair to ask this from a
> > new filesystem.
> >
> 
> This is what I posted in v2:
> 
>  - Handle security issues promptly.  Filesystems parse complex on-disk
>    structures from potentially untrusted media and must treat security
>    reports with urgency.  Expect the filesystem to be subjected to fuzzing
>    of both syscalls and filesystem images.  The filesystem must handle
>    corrupted input gracefully without hanging or crashing the kernel.
> 
> Are you saying that ext4 and others do not react to crash reports from
> image fuzzing which result in crash/hang?

I think it's more that nearly every filesystem has severe resource
constraints w.r.t. developer time, so reports from automated fuzzers are
assigned idle priority.

> Can you suggest a more relaxed clause or should I remove it altogether?

I think that what you've got there is a good expectation.  Each
filesystem implementation should have a mechanism to handle corruptions
with grace, and (presumably) new fuzz reports will result in patches
that use that graceful mechanism, whatever it is.

Anyone who wants specific response times to fuzzer reports can enter a
contract with a company or hire any of the many recently laid off
kernel people (or AISLOPFAFO) to provide SLA-like support.

--D