Filesystem drivers in Rust

Posted Dec 15, 2025 10:23 UTC (Mon) by farnz (subscriber, #17727)
In reply to: Filesystem drivers in Rust by taladar
Parent article: The state of the kernel Rust experiment

Depends how far the denial of service extends; if it just restricts you from accessing the malicious filesystem, that's not a problem, but if a malicious filesystem can cause the FS driver to hold locks that prevent you accessing any filesystem at all, that's a denial of service attack.

to post comments

Filesystem drivers in Rust

Posted Dec 15, 2025 12:54 UTC (Mon) by pizza (subscriber, #46) [Link] (2 responses)

> Depends how far the denial of service extends; if it just restricts you from accessing the malicious filesystem,

...How does one tell the difference between malicious and merely damaged?

(Because a "DoS" preventing accessing the former is arguably good, but arguably bad for the latter..)

Filesystem drivers in Rust

Posted Dec 15, 2025 12:57 UTC (Mon) by farnz (subscriber, #17727) [Link]

If the filesystem is damaged, all bets are off anyway - the damage may extend to the point where the data is irrecoverable. Thus, the contents of the damaged filesystem are already not part of "service" in a security sense, since you've already lost them.

As a quality of implementation matter, being able to retrieve as much data as possible from a damaged filesystem is nice, but it shouldn't affect availability of the system as a whole, only that one filesystem.

Filesystem drivers in Rust

Posted Dec 16, 2025 2:09 UTC (Tue) by corbet (editor, #1) [Link]

Linux has a number of filesystems that can deal properly with a "merely damaged" (corrupted filesystem). A maliciously corrupted filesystem will have correct metadata checksums, and is much harder to detect. There is a qualitative difference.