Re: [LSF/MM/BPF TOPIC] Where is fuse going? API cleanup, restructuring and more

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

On Tue, Mar 17, 2026 at 12:17:48PM +0800, Gao Xiang wrote:
> Hi Darrick,
> 
> On 2026/2/21 08:47, Darrick J. Wong wrote:
> > On Fri, Feb 06, 2026 at 02:15:12PM +0800, Gao Xiang wrote:
> 
> ...
> 
> > 
> > > > 
> > > > Fuse, otoh, is for all the other weird users -- you found an old
> > > > cupboard full of wide scsi disks; or management decided that letting
> > > > container customers bring their own prepopulated data partitions(!) is a
> > > > good idea; or the default when someone plugs in a device that the system
> > > > knows nothing about.
> 
> I brainstormed some more thoughts:
> 
> End users would like to mount a filesystem, but it's unknown that
> the filesystem is consistent or not, especially for filesystems
> are intended to be mounted as "rw", it's very hard to know if the
> filesystem metadata is fully consistent without a full fsck scan
> in advance.
> 
> Considering the following metadata inconsistent case (note that
> block 0x123 is referenced by the inconsistent metadata, rather
> than normal filesystem reflink with correct metadata):
> 
>  inode A (with high permission)
>  extent [0~4k)               maps to block 0x123
> 
>  random inode B (with low permission)
>  extent [0~4k)               maps to block 0x123 too
> 
> So there will exist at least three attack ways:
> 
>  1) Normal users will record the sensitive information to inode
>     A (since it's not the normal COW, the block 0x123 will be
>     updated in place), but normal users don't know there exists
>     the malicious inode B, so the sensitive information can be
>     fetched via inode B illegally;
> 
>  2) Attackers can write inode B with low permission in the proper
>     timing to change the inode A to compromise the computer
>     system;
> 
>  3) Of course, such two inodes can cause double freeing issues.
> 
> I think the normal copy-on-write (including OverlayFS) mechanism
> doesn't have the issue (because all changes will just have another
> copy). Of course, hardlinking won't have the same issue either,
> because there is only one inode for all hardlinks.

Yes, though you can screw with the link counts to cause other mayhem ;)

> I don't think FUSE-implemented userspace drivers will resolve
> such issues (I think users can only get the following usage reclaim:

Filesystem implementations /can/ detect these sorts of problems, but
most of them have no means to do that quickly.  As you and Demi Marie
have noted, the only reasonable way to guard against these things is
pre-mount fsck.

And even then, attackers still have a window to screw with the fs
metadata after fsck exits but before mount(2) takes the block device.
I guess you'd have to inject the fsck run after the O_EXCL opening.

Technically speaking fuse4fs could just invoke e2fsck -fn before it
starts up the rest of the libfuse initialization but who knows if that's
an acceptable risk.  Also unclear if you actually want -fy for that.

> "that is not the case that we will handle with userspace FUSE
> drivers, because the metadata is serious broken"), the only way to
> resolve such attack vectors is to run
> 
> the full-scan fsck consistency check and then mount "rw"
> 
> or
> 
> using the immutable filesystem like EROFS (so that there will not
> be such inconsisteny issues by design) and isolate the entire write
> traffic with a full copy-on-write mechanism with OverlayFS for
> example (IOWs, to make all write copy-on-write into another trusted
> local filesystem).

(Yeah, that's probably the only way to go for prepopulated images like
root filesystems and container packages)

> I hope it's a valid case, and that can indeed happen if the arbitary
> generic filesystem can be mounted in "rw".  And my immutable image
> filesystem idea can help mitigate this too (just because the immutable
> image won't be changed in any way, and all writes are always copy-up)

That, we agree on :)

--D

> Thanks,
> Gao Xiang
>