On Thu, Sep 11, 2025 at 03:27:00PM -0700, Darrick J. Wong wrote:
On Mon, Sep 08, 2025 at 11:15:48PM -0400, Theodore Ts'o via B4 Relay wrote:
From: Theodore Ts'o tytso@mit.edu
Unlike other strings in the ext4 superblock, we rely on tune2fs to make sure s_mount_opts is NUL terminated. Harden parse_apply_sb_mount_options() by treating s_mount_opts as a potential __nonstring.
Uh.... does that mean that a filesystem with exactly 64 bytes worth of mount option string (and no trailing null) could do something malicious?
Maybe.... I'm surprised syzkaller hasn't managed to create a maliciously fuzzed file system along these lines.
This was one of the things that I found while I was poking about in code that I hadn't examined in years. And I guess the kernel hardening folks have been looking for strndup() as a deprecated interface, but apparently they haven't targetted kstrndup() yet.
My guess is that s_usr_quota_inum mostly saves us, but a nastycrafted filesystem with more than 2^24 inodes could cause an out of bounds memory access? But that most likely will just fail the mount option parser anyway?
Actually, s_usr_quota_inum won't help, because s_mount_opts is copied into allocated memory using kstrndup(). So the buffer overrun is going to be in the allocated memory buffer, and since parse_options() uses strsep() it could potentially modify an adajacent string/buffer by replacing ',' and '=' bytes with NUL characters. I'll leave to security engineers to see if they can turn it into a usuable exploit, although I've always said that mounting untrusted file systems isn't a wise thing for a paranoid system administrator to do/allow, which is why I'm a big fan of your fuse2fs work. :-)
- Ted