On 4/21/26 08:20, Theodore Tso wrote:
> On Tue, Apr 21, 2026 at 07:32:43PM +0800, Zw Tang wrote:
>> This looks like an ext4 inline-data boundary/state inconsistency triggered
>> while writing to an ext4 image crafted by syzkaller. The later
>> KASAN: slab-use-after-free in rwsem_down_write_slowpath() appears to be a
>> secondary effect after the primary ext4 BUG, likely during teardown/unlink
>> after the filesystem failure.
> 
> Writing to a mounted image is not something that we consider a valid
> threat model.  If you can write to a mounted image, there are a
> zillion different ways that you can creash the kernel, or you can
> create a setuid shell, etc.
> 
> The upstream syzkaller bot makes sure that CONFIG_BLK_DEV_WRITE_MOUNTED
> is not defined to avoid syzkaller noise.

CONFIG_BLK_DEV_WRITE_MOUNTED only blocks writing via the specific block
device that is mounted.  It doesn't block writing via other methods.
If I recall correctly, its purpose was to prevent writing to the
buffer cache used by the filesystem driver.

Changing block devices that are mounted is also reachable via USB.
Yes, some distros may disable automount, but users who have stuff to
get done will mount USB devices anyway.  Telling users "don't do this"
very rarely works in practice.

I asked a distro maintainer about using libguestfs by default and
they refused, citing poor performance.  Unfortunately, there is no
way at the OS level to distinguish "trusted device used for backups"
and "untrusted USB stick".

So for now, neither distros nor kernel maintainers are willing to
budge, and in the meantime, users are left vulnerable.

The only ways out of this deadlock that I can see are either:

1. Make a tightly sandboxed FUSE daemon the default *and* fast.
   Ideally, it would:

   a. Run as an ephemeral user.
   b. Have the vast majority of syscalls blocked via seccomp.
   c. Have all access to /dev/fuse mediated by a validating proxy.
   d. Run in namespaces that block accessing any paths, even though
      the seccomp filter would already block any path-related syscalls.
   e. Support all the filesystems the kernel does, most likely via LKL.

2. Harden the kernel filesystem drivers against malicious devices,
   including TOCTOU.

Of course, it is also necessary to set usbcore.authorized_default=0
and use some form of port-based access control, so that one can use USB
keyboards without allowing a USB drive plugged in to act as a keyboard.

Maybe Linux should have been a microkernel after all...
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)