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! :)
-Kees
--
Kees Cook
