On Fri, Feb 06, 2026 at 05:12:34PM +0200, Andy Shevchenko wrote:
> On Fri, Feb 06, 2026 at 05:08:19PM +0200, Andy Shevchenko wrote:
> > On Fri, Feb 06, 2026 at 04:20:15PM +0200, Andy Shevchenko wrote:
> > > On Mon, Feb 02, 2026 at 12:19:45PM +0800, 李龙兴 wrote:
> > > > Dear Linux kernel developers and maintainers,
> > > >
> > > > We would like to report a new kernel bug found by our tool. The issue
> > > > is a WARNING in ext4_fill_super. Details are as follows.
> > >
> > > First of all, the warning appears in parse_apply_sb_mount_options().
> [...]
> Actually, the documentation says that strscpy*() must be used against
> C-strings.
> This can explain the bug, id est the given string in mount options is not
> NUL-terminated. That's where bug may come from. So, the Q is why is mount
> options
> not NUL-terminated when it comes to ext4_fill_super()?
parse_apply_sb_mount_options(...):
...
char s_mount_opts[64];
...
if (strscpy_pad(s_mount_opts, sbi->s_es->s_mount_opts) < 0)
return -E2BIG;
Is sbi->s_es->s_mount_opts expected to be a C string? If not, this
strscpy_pad() should likely be memtostr_pad(). (s_mount_opts is expected
to be a C string based on its use with later C string API calls.)
It seems like s_mount_opts is expected to be a C string, I can see it
being used that way in lots of other places, e.g.:
fs/ext4/ioctl.c: strscpy_pad(ret.mount_opts, es->s_mount_opts);
fs/ext4/ioctl.c: strscpy_pad(es->s_mount_opts, params->mount_opts);
fs/ext4/super.c: if (!sbi->s_es->s_mount_opts[0])
fs/ext4/super.c: if (strscpy_pad(s_mount_opts, sbi->s_es->s_mount_opts)
< 0)
I can't tell where es->s_mount_opts comes from originally?
This one:
fs/ext4/ioctl.c: strscpy_pad(es->s_mount_opts, params->mount_opts);
comes through ext4_ioctl_set_tune_sb() which has:
if (strnlen(params.mount_opts, sizeof(params.mount_opts)) ==
sizeof(params.mount_opts))
return -E2BIG;
So it's already checked for, and suggests it must be NUL-terminated.
> > > > loop4: detected capacity change from 0 to 514
> > > > ------------[ cut here ]------------
> > > > strnlen: detected buffer overflow: 65 byte read of buffer size 64
> > > > WARNING: CPU: 0 PID: 12320 at lib/string_helpers.c:1035
> > > > __fortify_report+0x9c/0xd0 lib/string_helpers.c:1035
> > > > [...]
> > > > Call Trace:
> > > > <TASK>
> > > > __fortify_panic+0x23/0x30 lib/string_helpers.c:1042
> > > > strnlen include/linux/fortify-string.h:235 [inline]
> > > > sized_strscpy include/linux/fortify-string.h:309 [inline]
> > > > parse_apply_sb_mount_options fs/ext4/super.c:2486 [inline]
> > > > __ext4_fill_super fs/ext4/super.c:5306 [inline]
> > > > ext4_fill_super+0x3972/0xaf70 fs/ext4/super.c:5736
> > > > get_tree_bdev_flags+0x38c/0x620 fs/super.c:1698
> > > > vfs_get_tree+0x8e/0x340 fs/super.c:1758
> > > > fc_mount fs/namespace.c:1199 [inline]
> > > > do_new_mount_fc fs/namespace.c:3642 [inline]
So, something via do_new_mount_fc? Probably:
static int ext4_fill_super(struct super_block *sb, struct fs_context *fc)
which calls __ext4_fill_super(), and eventually
parse_apply_sb_mount_options(). Which depends on:
struct ext4_fs_context *ctx = fc->fs_private;
But I can't figure out where that comes from. Seems like fs_parse(), but
I don't see where mount option strings would come through...
Anyone more familiar with this know?
-Kees
--
Kees Cook
