Re: [BUG] ext4: BUG_ON in ext4_write_inline_data (fs/ext4/inline.c:240)

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

On Tue, Apr 28, 2026 at 04:50:14PM -0400, Demi Marie Obenour wrote:
> This is an example of a BadUSB attack, which has been known since
> at least 2014.  USB sticks *do* have their own microcontrollers to
> run their firmware.  At least in the past this firmware has been
> programmable and not been digitally signed.  This means that the USB
> stick *can* be reprogrammed to perform a TOCTOU attack on a filesystem,
> or indeed to implement a completely different kind of USB device.

Honestly, if that's what you are worried about, then best solution is
put epoxy in every single USB port.  I've since financial institutions
that have done precisely this, and both Android and Chrome OS supports
enterprise security policies which does the equivalent in software.

> Protecting against replay attacks requires a Merkle tree.  The only
> Linux filesystems that I know have one are ZFS, bcachefs, and BTRFS.
> The first two are out of tree and the third is not shipped in RHEL
> at least.

FYI, there was a patch for btrfs, but it was never landed.  It's
unclear how many people would be willing to pay the performance tax of
using hmac-sha256 for every single data and metadata block write.   

> Of course, you are free to choose which (if any) of these attacks you
> care about.  One can that USB sticks should be mounted in userspace,
> UEFI secure boot with Microsoft keys is irrelevant as long as
> administrator -> kernel isn't a security boundary on Windows, and that
> confidential computing only makes sense for stateless workloads (which
> can use dm-verity) until there is a way to trust storage devices.
> But it's always best to be aware that an attack vector exists,
> whether or not one chooses to address it.

Sure, but a drive-by comment on a patch review advocating that we slow
down ext4 to protect a single instance where the attacker has
read/write access to a mounted block device, when the file system
doesn't have generalized protections against that whole class of
attacks.... isn't particularly helpful.

By the way, I'm not aware of *any* company that has been interested in
funding work to protect against this class of attacks.  Given that
most file system developers prefer food with their meals, and have
enough *other* unfunded mandates from our user community, it doesn't
seem likely that we're going to see much forward progress towards your
desires/interests.

Cheers,

					- Ted