Re: [Kernel Bug] WARNING in ext4_fill_super

Re: [Kernel Bug] WARNING in ext4_fill_super

[Andy Shevchenko]

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().

> Kernel commit: v6.18.2
> Kernel config: see attachment
> report: see attachment

Second, you should include people based on the actual subsystem, unless it's
proven that the problem is in lib/*.

Cc'ed to ext4.

> We are currently analyzing the root cause and  working on a
> reproducible PoC. We will provide further updates in this thread as
> soon as we have more information.


> 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
> Modules linked in:
> CPU: 0 UID: 0 PID: 12320 Comm: syz.4.59 Not tainted 6.18.2 #1 PREEMPT(full)
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
> RIP: 0010:__fortify_report+0x9c/0xd0 lib/string_helpers.c:1035
> Code: ed 48 c7 c0 80 c8 cf 8b 48 0f 44 d8 e8 cd dd 17 fd 4d 89 e0 48
> 89 ea 4c 89 f6 48 89 d9 48 c7 c7 00 c9 cf 8b e8 b5 57 d6 fc 90 <0f> 0b
> 90 90 5b 5d 41 5c 41 5d 41 5e c3 cc cc cc cc 48 89 de 48 c7
> RSP: 0018:ffffc90011f9fa18 EFLAGS: 00010282
> RAX: 0000000000000000 RBX: ffffffff8bcfc880 RCX: ffffffff817afc38
> RDX: ffff8881095eca80 RSI: ffffffff817afc45 RDI: 0000000000000001
> RBP: 0000000000000041 R08: 0000000000000001 R09: 0000000000000000
> R10: 0000000000000001 R11: 0000000000000001 R12: 0000000000000040
> R13: 0000000000000000 R14: ffffffff8bcfd240 R15: ffff88803c484400
> FS:  00007f9e5f45c640(0000) GS:ffff8880cf053000(0000) knlGS:0000000000000000
> CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 0000000000000000 CR3: 0000000123400000 CR4: 0000000000752ef0
> PKRU: 80000000
> 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]
>  do_new_mount fs/namespace.c:3718 [inline]
>  path_mount+0x7b9/0x23a0 fs/namespace.c:4028
>  do_mount fs/namespace.c:4041 [inline]
>  __do_sys_mount fs/namespace.c:4229 [inline]
>  __se_sys_mount fs/namespace.c:4206 [inline]
>  __x64_sys_mount+0x293/0x310 fs/namespace.c:4206
>  do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
>  do_syscall_64+0xcd/0xfa0 arch/x86/entry/syscall_64.c:94
>  entry_SYSCALL_64_after_hwframe+0x77/0x7f
> RIP: 0033:0x56755e
> Code: 48 c7 c0 ff ff ff ff eb aa e8 3e 1c 00 00 66 2e 0f 1f 84 00 00
> 00 00 00 0f 1f 40 00 f3 0f 1e fa 49 89 ca b8 a5 00 00 00 0f 05 <48> 3d
> 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48
> RSP: 002b:00007f9e5f45bdf8 EFLAGS: 00000246 ORIG_RAX: 00000000000000a5
> RAX: ffffffffffffffda RBX: 00007f9e5f45be80 RCX: 000000000056755e
> RDX: 0000000020000140 RSI: 0000000020000440 RDI: 00007f9e5f45be40
> RBP: 0000000020000140 R08: 00007f9e5f45be80 R09: 0000000000000000
> R10: 0000000000000000 R11: 0000000000000246 R12: 0000000020000440
> R13: 00007f9e5f45be40 R14: 00000000000003d5 R15: 0000000020000200
>  </TASK>
> 
> https://drive.google.com/file/d/12W8B3IU88RBdBpV4nMcAj9TVOzlx6xL-/
> https://drive.google.com/file/d/1efTUJTmSTMuJqSpCq686RjXdUzhyEJDL/

-- 
With Best Regards,
Andy Shevchenko

Re: [Kernel Bug] WARNING in ext4_fill_super

[Andy Shevchenko]

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().
> 
> > Kernel commit: v6.18.2
> > Kernel config: see attachment
> > report: see attachment
> 
> Second, you should include people based on the actual subsystem, unless it's
> proven that the problem is in lib/*.
> 
> Cc'ed to ext4.
> 
> > We are currently analyzing the root cause and  working on a
> > reproducible PoC. We will provide further updates in this thread as
> > soon as we have more information.

You need to add more information here, esp. about the tested environment,
architecture, and compiler (I can deduct some from the .config, but still...).

So, as far as I can see this may only happen in the case when _Static_assert()
is evaluated to something that strict { $SMTH } is meaningful to the
preprocessor to have sizeof() > 0 (or sizeof(struct {}) is > 0).

In both cases sounds like a compiler bug.

Other possible explanation is the instrumentation that makes sizeof($FOO[])
return bigger sizes.

But TBH, all of the above looks to me like a nonsense. Maybe I missed something.

Note, if strscpy_pad(a, b) is broken, it should be much more visible and much
easier to reproduce even without syzkaller. Do we have (Kunit) test cases for
strscpy*()? If not, you should start adding them first.

> > 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
> > Modules linked in:
> > CPU: 0 UID: 0 PID: 12320 Comm: syz.4.59 Not tainted 6.18.2 #1 PREEMPT(full)
> > Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
> > RIP: 0010:__fortify_report+0x9c/0xd0 lib/string_helpers.c:1035
> > Code: ed 48 c7 c0 80 c8 cf 8b 48 0f 44 d8 e8 cd dd 17 fd 4d 89 e0 48
> > 89 ea 4c 89 f6 48 89 d9 48 c7 c7 00 c9 cf 8b e8 b5 57 d6 fc 90 <0f> 0b
> > 90 90 5b 5d 41 5c 41 5d 41 5e c3 cc cc cc cc 48 89 de 48 c7
> > RSP: 0018:ffffc90011f9fa18 EFLAGS: 00010282
> > RAX: 0000000000000000 RBX: ffffffff8bcfc880 RCX: ffffffff817afc38
> > RDX: ffff8881095eca80 RSI: ffffffff817afc45 RDI: 0000000000000001
> > RBP: 0000000000000041 R08: 0000000000000001 R09: 0000000000000000
> > R10: 0000000000000001 R11: 0000000000000001 R12: 0000000000000040
> > R13: 0000000000000000 R14: ffffffff8bcfd240 R15: ffff88803c484400
> > FS:  00007f9e5f45c640(0000) GS:ffff8880cf053000(0000) knlGS:0000000000000000
> > CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> > CR2: 0000000000000000 CR3: 0000000123400000 CR4: 0000000000752ef0
> > PKRU: 80000000
> > 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]
> >  do_new_mount fs/namespace.c:3718 [inline]
> >  path_mount+0x7b9/0x23a0 fs/namespace.c:4028
> >  do_mount fs/namespace.c:4041 [inline]
> >  __do_sys_mount fs/namespace.c:4229 [inline]
> >  __se_sys_mount fs/namespace.c:4206 [inline]
> >  __x64_sys_mount+0x293/0x310 fs/namespace.c:4206
> >  do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
> >  do_syscall_64+0xcd/0xfa0 arch/x86/entry/syscall_64.c:94
> >  entry_SYSCALL_64_after_hwframe+0x77/0x7f
> > RIP: 0033:0x56755e
> > Code: 48 c7 c0 ff ff ff ff eb aa e8 3e 1c 00 00 66 2e 0f 1f 84 00 00
> > 00 00 00 0f 1f 40 00 f3 0f 1e fa 49 89 ca b8 a5 00 00 00 0f 05 <48> 3d
> > 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48
> > RSP: 002b:00007f9e5f45bdf8 EFLAGS: 00000246 ORIG_RAX: 00000000000000a5
> > RAX: ffffffffffffffda RBX: 00007f9e5f45be80 RCX: 000000000056755e
> > RDX: 0000000020000140 RSI: 0000000020000440 RDI: 00007f9e5f45be40
> > RBP: 0000000020000140 R08: 00007f9e5f45be80 R09: 0000000000000000
> > R10: 0000000000000000 R11: 0000000000000246 R12: 0000000020000440
> > R13: 00007f9e5f45be40 R14: 00000000000003d5 R15: 0000000020000200
> >  </TASK>
> > 
> > https://drive.google.com/file/d/12W8B3IU88RBdBpV4nMcAj9TVOzlx6xL-/
> > https://drive.google.com/file/d/1efTUJTmSTMuJqSpCq686RjXdUzhyEJDL/

-- 
With Best Regards,
Andy Shevchenko

Re: [Kernel Bug] WARNING in ext4_fill_super

[Andy Shevchenko]

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().
> > 
> > > Kernel commit: v6.18.2
> > > Kernel config: see attachment
> > > report: see attachment
> > 
> > Second, you should include people based on the actual subsystem, unless it's
> > proven that the problem is in lib/*.
> > 
> > Cc'ed to ext4.
> > 
> > > We are currently analyzing the root cause and  working on a
> > > reproducible PoC. We will provide further updates in this thread as
> > > soon as we have more information.
> 
> You need to add more information here, esp. about the tested environment,
> architecture, and compiler (I can deduct some from the .config, but still...).
> 
> So, as far as I can see this may only happen in the case when _Static_assert()
> is evaluated to something that strict { $SMTH } is meaningful to the
> preprocessor to have sizeof() > 0 (or sizeof(struct {}) is > 0).
> 
> In both cases sounds like a compiler bug.
> 
> Other possible explanation is the instrumentation that makes sizeof($FOO[])
> return bigger sizes.
> 
> But TBH, all of the above looks to me like a nonsense. Maybe I missed something.

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()?

> Note, if strscpy_pad(a, b) is broken, it should be much more visible and much
> easier to reproduce even without syzkaller. Do we have (Kunit) test cases for
> strscpy*()? If not, you should start adding them first.
> 
> > > 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
> > > Modules linked in:
> > > CPU: 0 UID: 0 PID: 12320 Comm: syz.4.59 Not tainted 6.18.2 #1 PREEMPT(full)
> > > Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
> > > RIP: 0010:__fortify_report+0x9c/0xd0 lib/string_helpers.c:1035
> > > Code: ed 48 c7 c0 80 c8 cf 8b 48 0f 44 d8 e8 cd dd 17 fd 4d 89 e0 48
> > > 89 ea 4c 89 f6 48 89 d9 48 c7 c7 00 c9 cf 8b e8 b5 57 d6 fc 90 <0f> 0b
> > > 90 90 5b 5d 41 5c 41 5d 41 5e c3 cc cc cc cc 48 89 de 48 c7
> > > RSP: 0018:ffffc90011f9fa18 EFLAGS: 00010282
> > > RAX: 0000000000000000 RBX: ffffffff8bcfc880 RCX: ffffffff817afc38
> > > RDX: ffff8881095eca80 RSI: ffffffff817afc45 RDI: 0000000000000001
> > > RBP: 0000000000000041 R08: 0000000000000001 R09: 0000000000000000
> > > R10: 0000000000000001 R11: 0000000000000001 R12: 0000000000000040
> > > R13: 0000000000000000 R14: ffffffff8bcfd240 R15: ffff88803c484400
> > > FS:  00007f9e5f45c640(0000) GS:ffff8880cf053000(0000) knlGS:0000000000000000
> > > CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> > > CR2: 0000000000000000 CR3: 0000000123400000 CR4: 0000000000752ef0
> > > PKRU: 80000000
> > > 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]
> > >  do_new_mount fs/namespace.c:3718 [inline]
> > >  path_mount+0x7b9/0x23a0 fs/namespace.c:4028
> > >  do_mount fs/namespace.c:4041 [inline]
> > >  __do_sys_mount fs/namespace.c:4229 [inline]
> > >  __se_sys_mount fs/namespace.c:4206 [inline]
> > >  __x64_sys_mount+0x293/0x310 fs/namespace.c:4206
> > >  do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
> > >  do_syscall_64+0xcd/0xfa0 arch/x86/entry/syscall_64.c:94
> > >  entry_SYSCALL_64_after_hwframe+0x77/0x7f
> > > RIP: 0033:0x56755e
> > > Code: 48 c7 c0 ff ff ff ff eb aa e8 3e 1c 00 00 66 2e 0f 1f 84 00 00
> > > 00 00 00 0f 1f 40 00 f3 0f 1e fa 49 89 ca b8 a5 00 00 00 0f 05 <48> 3d
> > > 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48
> > > RSP: 002b:00007f9e5f45bdf8 EFLAGS: 00000246 ORIG_RAX: 00000000000000a5
> > > RAX: ffffffffffffffda RBX: 00007f9e5f45be80 RCX: 000000000056755e
> > > RDX: 0000000020000140 RSI: 0000000020000440 RDI: 00007f9e5f45be40
> > > RBP: 0000000020000140 R08: 00007f9e5f45be80 R09: 0000000000000000
> > > R10: 0000000000000000 R11: 0000000000000246 R12: 0000000020000440
> > > R13: 00007f9e5f45be40 R14: 00000000000003d5 R15: 0000000020000200
> > >  </TASK>
> > > 
> > > https://drive.google.com/file/d/12W8B3IU88RBdBpV4nMcAj9TVOzlx6xL-/
> > > https://drive.google.com/file/d/1efTUJTmSTMuJqSpCq686RjXdUzhyEJDL/

-- 
With Best Regards,
Andy Shevchenko

Re: [Kernel Bug] WARNING in ext4_fill_super

[Kees Cook]

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

Re: [Kernel Bug] WARNING in ext4_fill_super

[Kees Cook]

On Fri, Feb 06, 2026 at 11:29:11AM -0800, Kees Cook wrote:
> 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...

Oh! This is coming directly from disk. So we need an in-place sanity
check. How about this?


diff --git a/fs/ext4/super.c b/fs/ext4/super.c
index 87205660c5d0..9ad6005615d8 100644
--- a/fs/ext4/super.c
+++ b/fs/ext4/super.c
@@ -2485,6 +2485,13 @@ static int parse_apply_sb_mount_options(struct super_block *sb,
 	if (!sbi->s_es->s_mount_opts[0])
 		return 0;
 
+	if (strnlen(sbi->s_es->s_mount_opts, sizeof(sbi->s_es->s_mount_opts)) ==
+	    sizeof(sbi->s_es->s_mount_opts)) {
+		ext4_msg(sb, KERN_ERR,
+			 "Mount options in superblock are not NUL-terminated");
+		return -EINVAL;
+	}
+
 	if (strscpy_pad(s_mount_opts, sbi->s_es->s_mount_opts) < 0)
 		return -E2BIG;
 

-- 
Kees Cook

Re: [Kernel Bug] WARNING in ext4_fill_super

[Kees Cook]

On Fri, Feb 06, 2026 at 11:53:09AM -0800, Kees Cook wrote:
> On Fri, Feb 06, 2026 at 11:29:11AM -0800, Kees Cook wrote:
> > 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...
> 
> Oh! This is coming directly from disk. So we need an in-place sanity
> check. How about this?
> 
> 
> diff --git a/fs/ext4/super.c b/fs/ext4/super.c
> index 87205660c5d0..9ad6005615d8 100644
> --- a/fs/ext4/super.c
> +++ b/fs/ext4/super.c
> @@ -2485,6 +2485,13 @@ static int parse_apply_sb_mount_options(struct super_block *sb,
>  	if (!sbi->s_es->s_mount_opts[0])
>  		return 0;
>  
> +	if (strnlen(sbi->s_es->s_mount_opts, sizeof(sbi->s_es->s_mount_opts)) ==
> +	    sizeof(sbi->s_es->s_mount_opts)) {
> +		ext4_msg(sb, KERN_ERR,
> +			 "Mount options in superblock are not NUL-terminated");
> +		return -EINVAL;
> +	}
> +
>  	if (strscpy_pad(s_mount_opts, sbi->s_es->s_mount_opts) < 0)
>  		return -E2BIG;

Oh, wait. I see these commits now:

8ecb790ea8c3 ("ext4: avoid potential buffer over-read in parse_apply_sb_mount_options()")
ee5a977b4e77 ("ext4: fix string copying in parse_apply_sb_mount_options()")

Ugh, the history is that fundamentally s_mount_opts should be
__nonstring. Old code handled this fine (by using kstrndup), but when
ioctl get/set was added in commit 04a91570ac67 ("ext4: implemet new
ioctls to set and get superblock parameters"), s_mount_opts started
being treated as a C string, which would lead to over-reads (due to lack
of NUL-termination).

So, should on-disk s_mount_opts be required to be NUL-terminated? I
would argue yes, since right now a mount of such a thing will crash with
the reported failure in this thread. So likely, my proposed fix is the
best option?

-Kees

-- 
Kees Cook