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@xxxxxxx> > > > > 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
