On Mon, Feb 09, 2026 at 12:00:36PM -0800, Kees Cook wrote:
> On Mon, Feb 09, 2026 at 08:27:50PM +0300, Fedor Pchelkin wrote:
> > Kees Cook wrote:
> > > ee5a977b4e77 ("ext4: fix string copying in
> > > parse_apply_sb_mount_options()")
> > > Notices the loud failures of strscpy_pad() introduced by 8ecb790ea8c3,
> > > and attempted to silence them by making the destination 64 and rejecting
> > > too-long strings from the on-disk copy of s_mount_opts, but didn't
> > > actually solve it at all, since the problem was always the over-read
> > > of the source seen by strnlen(). (Note that the report quoted in this
> > > commit exactly matches the report today.)
> > >
> >
> > [...]
> >
> > > Reported-by: 李龙兴 <[email protected]>
> > > Closes:
> > > https://lore.kernel.org/lkml/cahpqnmzbb2lruma6jymohxqrsoiakmfz1wvez8jcykg4u6t...@mail.gmail.com/
> > > Fixes: ee5a977b4e77 ("ext4: fix string copying in
> > > parse_apply_sb_mount_options()")
> >
> > Hi there,
> >
> > [ I'd better be Cc'ed as the author of the commit in Fixes ]
>
> Agreed! Sorry I missed adding you to Cc.
>
> > The mentioned reports are for v6.18.2 kernel while ee5a977b4e77 ("ext4:
> > fix string copying in parse_apply_sb_mount_options()") landed in v6.18.3.
> > Back at the time I've tested the patch with different bogus s_mount_opts
> > values and the fortify warnings should have been gone.
>
> Ah-ha! Okay, thank you for catching this versioning issue. I had been
> scratching my head over how it could have been the same warning. This
> report is effectively a duplicate of the report you fixed with
> ee5a977b4e77.
>
> > I don't think there is an error in ee5a977b4e77 unless these warnings
> > actually appear on the latest kernels with ee5a977b4e77 applied.
> >
> > > @@ -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;
> > > + }
> >
> > strscpy_pad() returns -E2BIG if the source string was truncated. This
> > happens for the above condition as well - the last byte is truncated and
> > replaced with a NUL-terminator.
>
> Yeah, I've double-checked this now. The second half of the overflow
> check in the fortified strnlen eluded by eyes when I went through this
> originally. Thanks for sanity checking this!
>
> > The check at 3db63d2c2d1d ("ext4: check if mount_opts is NUL-terminated in
> > ext4_ioctl_set_tune_sb()") was done in that manner as there is currently
> > no way to propagate strscpy_pad() return value up from ext4_sb_setparams().
> > So the string is independently checked inside ext4_ioctl_set_tune_sb()
> > directly.
> >
> >
> > As for the 64/65 byte length part, now the rationale of the checks works
> > as Darrick Wong described at the other part of this thread and corresponds
> > to how relevant userspace stuff treats the s_mount_opts field: the buffer
> > is at most 63 payload characters long + NUL-terminator. Jan Kara also
> > shared similar thoughts during the discussion of ee5a977b4e77 [1].
> >
> > [1]:
> > https://lore.kernel.org/linux-ext4/yq6rbx54jt4btntsh37urd6u63wwcd3lyhovbrm6w7occaveea@riljfkx5jmhi/
>
> Okay, great. I figure I can do two things:
>
> 1) rework this patch with adjusted commit log to reflect the notes
> raised so far, so that we reject mounts that lack a NUL-terminated
> s_mount_opts (as silent truncation may induce an unintended option
> string, e.g. "...,journal_path=/dev/sda2" into "...,journal_path=/dev/sda"
> or something weird like that).
>
> 2) Leave everything as-is, live with above corner case since it should
> be unreachable with userspace tooling as they have always existed.
>
> I'm fine either way! :)
I'd pick #1, unless someone knows of a userspace program that could have
set a 64-byte s_mount_ops string with no null terminator. I didn't find
any, but there are many implementations of ext4 out there. :/
(and yes, it's better to reject an unterminated s_mount_opts than
accidentally point the kernel at the wrong block device)
--D
> -Kees
>
> --
> Kees Cook
>
