linux-kernel - Re: [Kernel Bug] WARNING in ext4_fill

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <202602061032.63DD1CA3AE@keescook>
Date: Fri, 6 Feb 2026 11:29:11 -0800
From: Kees Cook <kees@...nel.org>
To: Andy Shevchenko <andriy.shevchenko@...el.com>
Cc: 李龙兴 <coregee2000@...il.com>,
	Theodore Ts'o <tytso@....edu>,
	Andreas Dilger <adilger.kernel@...ger.ca>,
	linux-ext4@...r.kernel.org, syzkaller@...glegroups.com,
	andy@...nel.org, akpm@...ux-foundation.org,
	linux-hardening@...r.kernel.org, linux-kernel@...r.kernel.org,
	linux-fsdevel@...r.kernel.org
Subject: Re: [Kernel Bug] WARNING in ext4_fill_super

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