Back when I was poking around with filesystem fuzzing stuff years back, I noticed something odd:

An EXT filesystem can tell the Linux OS how it should behave "if" the filesystem is corrupt, including triggering a kernel panic. In a world where USB thumb drives exist, this seems... not ideal.

Let's see what happens if we plug such a mass storage device into a fully patched Chromebook in 2024...

Oh.

The man page for tune2fs is pretty clear about this capability.

The person who writes the data to the USB mass storage device can specify that both:
1) The OS that reads the device should panic if the filesystem has an error.
2) The filesystem has an error.

🤦‍♂️

Modern Linux distros aren't really affected by this. At least in a drive-by sense. Auto-mounting is handled in a safer way than simply telling the kernel to mount the filesystem you just plugged in.

For example, compare the Ubuntu 22.04 behavior (complain that the filesystem is corrupt) vs. Ubuntu 20.04 (panic and reboot). For modern Linux to see the panic, you'd have to manually mount the filesystem (as root/sudo).

ChromeOS, on the other hand, chooses the more YOLO route of auto-mounting via the kernel.

@wdormann I just changed the fstab entry for my /boot partition, as that one's not encrypted and could be used by someone with physical access to send my machine into a boot loop, maybe.
@cm
We'll, they'd need to be on your computer as root to mess with your /boot.
And if an attacker has that level of access, they can do whatever they want. 😀
@wdormann An "evil maid" type attack would suffice, I run encrypted filesystems except for /boot, and this attack might be a denial of service even with secure boot activated. Once you know what's happening it's easily fixed with a linux live CD, but I guess you could confuse the heck out of even seasoned linux admins...