Re: REJECTED: CVE-2025-0927: heap overflow in the hfs and hfsplus filesystems with manually crafted filesystem

["Theodore Ts'o" <tytso@mit.edu>]

On Tue, May 13, 2025 at 06:09:24PM +0200, Dmitry Vyukov wrote:
> 
> Ted, have you read what this thread is about? :)
> I was talking only about images that fail fsck.

If it fails fsck, don't mount the !@?@# image.  For ext4, we can fix
pretty much any corrption, so using fsck.ext4 -y should work for nearly all
file system images.

> Re headcount, if we want that to ever happen, shouldn't we do what I proposed?

Do what?  Tell users that they should be able to mount untrusted file
systems that fail fsck, and after we have a catastrophic security
failure, hope that someone will fund it?  I don't think that's very
responsible.

Or did you mean spamming open source volunteers with syzbot reports
hoping that you can shame/abuse them to do the work for free?  Sorry,
that's not going to work.  It's just way too much of a lift ---
multiple SWE-years worth of work is not something that I'm going to do
after midnight or on weekends.

If you really want to mount file systesms that fail fsck, or you're
too lazy to run fsck on untrusted images (and this shouldn't be hard
to teach the desktop software check the file system automatically
before auto-mounting it), then another possibility is:

> > If you want to be even more paranoid (or the proprietary file system
> > doesn't have a good fsck), you could mount the file system via a guest
> > kernel running in a VM, where the VM is locked down using a seccomp
> > sandbox, and which provides file system services via 9pfs to the host
> > kernel.  9pfs is a remote file system which is easy to audit, and this
> > is a key part of the security strategy used by gVisor.

       	     	     	 	  	   - Ted