public inbox for linux-ext4@vger.kernel.org
 help / color / mirror / Atom feed
From: "Theodore Tso" <tytso@mit.edu>
To: Demi Marie Obenour <demiobenour@gmail.com>
Cc: Zw Tang <shicenci@gmail.com>,
	Andreas Dilger <adilger.kernel@dilger.ca>,
	libaokun@linux.alibaba.com, jack@suse.cz, ojaswin@linux.ibm.com,
	linux-ext4@vger.kernel.org, linux-kernel@vger.kernel.org,
	yi.zhang@huawei.com, syzkaller-bugs@googlegroups.com
Subject: Re: [BUG] ext4: BUG_ON in ext4_write_inline_data (fs/ext4/inline.c:240)
Date: Sat, 25 Apr 2026 23:22:11 -0400	[thread overview]
Message-ID: <20260426032211.GD22489@macsyma-wired.lan> (raw)
In-Reply-To: <4e76eb68-862d-4b9f-8242-e6aced2704ee@gmail.com>

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?

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.

Cheers,

						- Ted

  reply	other threads:[~2026-04-26  3:23 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-04-21 11:32 [BUG] ext4: BUG_ON in ext4_write_inline_data (fs/ext4/inline.c:240) Zw Tang
2026-04-21 12:20 ` Theodore Tso
2026-04-25 18:00   ` Demi Marie Obenour
2026-04-26  3:22     ` Theodore Tso [this message]
2026-04-21 12:25 ` Jan Kara

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260426032211.GD22489@macsyma-wired.lan \
    --to=tytso@mit.edu \
    --cc=adilger.kernel@dilger.ca \
    --cc=demiobenour@gmail.com \
    --cc=jack@suse.cz \
    --cc=libaokun@linux.alibaba.com \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=ojaswin@linux.ibm.com \
    --cc=shicenci@gmail.com \
    --cc=syzkaller-bugs@googlegroups.com \
    --cc=yi.zhang@huawei.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox