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: <aYYD3rxyIfdH2R-d@smile.fi.intel.com>
Date: Fri, 6 Feb 2026 17:08:14 +0200
From: Andy Shevchenko <andriy.shevchenko@...el.com>
To: 李龙兴 <coregee2000@...il.com>,
	Theodore Ts'o <tytso@....edu>,
	Andreas Dilger <adilger.kernel@...ger.ca>,
	linux-ext4@...r.kernel.org
Cc: syzkaller@...glegroups.com, kees@...nel.org, andy@...nel.org,
	akpm@...ux-foundation.org, linux-hardening@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [Kernel Bug] WARNING in ext4_fill_super

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