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

[Demi Marie Obenour <demiobenour@gmail.com>]

[-- Attachment #1.1.1: Type: text/plain, Size: 3806 bytes --]

On 4/25/26 23:22, Theodore Tso wrote:
> On Sat, Apr 25, 2026 at 02:00:23PM -0400, Demi Marie Obenour wrote:
>>
>> 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.
> 
> How can an unprivileged user change the contents of a USB device while
> it is mounted?
> 
> Are you positing evil USB devices that can return block contents A at
> time t, and block contents B at time t+1?

Correct.

> The threat model that we are using is that if the USB device is set to
> a particular state *before* the file system is mounted, and then the
> KGB scatters the USB device in the parking lot, and then someone picks
> up the USB device in the Raytheon parking lot, and says, "hey, free
> hardware", takes it into the classified machinem room, inserts it into
> the server, and mounts it.  This might be considered likely or not
> likely, but speaking as someone who has been in a top secret machine
> room at a defense contractor, they were *way* less protected than what
> I've seen at a financial services company, or at a data center at a
> hyperscaler.
> 
> But be that as it may, even *then* you're not modifying the block
> device while it is mounted.
> 
>> 2. Harden the kernel filesystem drivers against malicious devices,
>>    including TOCTOU.
> 
> Malicious devices that have their own microcomputer and can change the
> block contents under the control of the attacker is *just* not
> something I care about.  I also don't think it's a particularly
> realistic threat model.

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.

There are also attacks possible in confidential computing scenarios.
dm-verity protects against both tampering and replay attacks,
but it is read-only.  dm-crypt and dm-integrity are writable, but
dm-crypt does not block tampering and dm-verity does not block replay
of a previously stored sector.

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.

If dm-integrity is used, an attacker can return an old value that
was stored at a given block in the past.  With only dm-crypt, an
attacker can replace any cipher block (typically 16 bytes) with
either its old contents or garbage the attacker doesn't control.
If this can be used to compromise a confidential VM, this violates
the confidential computing security boundary.

Finally, this can be used to violate kernel lockdown, breaking the
guarantees UEFI secure boot is supposed to provide.  Whether that is
worth caring about is a totally different question of course.

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.
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 7253 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]