Re: [PATCH] ext4: Reject on-disk mount options with missing NUL-terminator

[Kees Cook <kees@kernel.org>]

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: 李龙兴 <coregee2000@gmail.com>
> > Closes: https://lore.kernel.org/lkml/CAHPqNmzBb2LruMA6jymoHXQRsoiAKMFZ1wVEz8JcYKg4U6TBbw@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