Re: [PATCH] ext4: xattr: fix out-of-bounds access in ext4_xattr_set_entry

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

On Thu, Mar 19, 2026 at 07:13:45PM +0800, ZhengYuan Huang wrote:
> 
> And yes, the reproducer does involve actively modifying the mounted
> filesystem image. We use ublk to enable this behavior.

We don't consider bugs which involve modfying the mounted filesystem
as valid from a security perspective.  In particular, I don't want to
add checks to hotpaths to try to protect against these sorts of
failures, because they simply shouldn't be allowed --- and/or if the
attacker has write access to the block device while the file system is
mounted, you've basically lost already.

We have added the ioctl EXT4_IOC_SET_TUNE_SB_PARAM to more recent
kernels, and will be teaching tune2fs to use that instead of modifying
the mounted file system directly.  Once that happens, we will add a
kernel configuration option which works like
CONFIG_BLK_DEV_WRITE_MOUNTED, but which is ext4 specific; so that for
distributions that are shipping a sufficiently new version of
e2fsprogs, they can block write access to mounted ext4 file systems.
Quoting from Kconfig documentation for CONFIG_BLK_DEV_WRITE_MOUNTED:

        When a block device is mounted, writing to its buffer cache is very
        likely going to cause filesystem corruption. It is also rather easy to
        crash the kernel in this way since the filesystem has no practical way
        of detecting these writes to buffer cache and verifying its metadata
        integrity. However there are some setups that need this capability
        like running fsck on read-only mounted root device, modifying some
        features on mounted ext4 filesystem, and similar. If you say N, the
        kernel will prevent processes from writing to block devices that are
        mounted by filesystems which provides some more protection from runaway
        privileged processes and generally makes it much harder to crash
        filesystem drivers.

The official syzkaller instance sets CONFIG_BLK_DEV_WRITE_MOUNTED to
"no" and we've asked them to block fuzzers which try to modify the
file used by loopback mounts, because these sorts of syzkaller reports
are pure noise as far as we are concerned.

If system administrators are stupid enough to make the block device
world writeable, they deserve everything they get.  Similarly, if
system administrators don't run fsck on random USB thumb drive dropped
in the parking lot by the MSS or the KGB before mounting it, again,
the bug is between the chair and keyboard.  (For that matter,
inserting a random USB device for which you aren't sure whether it
came from a trusted source can make you vulnerable to hardware-level
attacks.  Just don't do it.)

That being said, we are more likely to accept patches to address
static file system corruption, but the checks need to be done when the
metadata in question is first loaded, and outside of a hot path.  But
trying to defend against dynamic modifications of the block device is
really a fools errand, without completely trashing the performance of
the file system.

Cheers,

					- Ted