Re: [syzbot] [ext4?] kernel panic: EXT4-fs (device loop0): panic forced after error (3)

[Eric Biggers]

On Thu, Aug 17, 2023 at 12:11:18PM -0400, Theodore Ts'o wrote:
> On Thu, Aug 17, 2023 at 09:47:48AM -0500, Eric Sandeen wrote:
> > 
> > Just to play devil's advocate here - (sorry) - I don't see this as any
> > different from any other "malicious" filesystem image.
> > 
> > I've never been a fan of the idea that malicious images are real security
> > threats, but whether the parking lot USB stick paniced the box in an
> > unexpected way or "on purpose," the result is the same ...
> > 
> > I wonder if it might make sense to put EXT4_MOUNT_ERRORS_PANIC under a
> > sysctl or something, so that admins can enable it only when needed.
> 
> Well, if someone is stupid enough to plug in a parking lot USB stick
> into their system, they get everything they deserve.  And a forced
> panic isn't going to lead a more privilege escalation attack, so I
> really don't see a problem if a file system which is marked "panic on
> error", well, causes a panic.  It's a good way of (harmlessly)
> punishing stupid user tricks.  :-)
> 
> The other way of thinking about it is that if your threat model
> includes an attacker with physical access to the server with a USB
> port, attacks include a cable which has a USB port on one side, and a
> 120V/240V AC mains plug on the the other.  This will very likely cause
> a system shutdown, even if they don't have automount enabled.   :-)
> 

Eric S. is correct that for a filesystem image to enable panic on error, support
for panic on error should have to be properly consented to by the kernel
configuration, for example through an fs.allow_panic_on_error sysctl.

It can be argued that this not important, or not worth implementing when the
default will need to remain 1 for backwards compatibility.  Or even that
syzkaller should work around it in the mean time.  But it is incorrect to write
"This is fundamentally a syzbot bug."

- Eric