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

["Darrick J. Wong" <djwong@kernel.org>]

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: 李龙兴 <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! :)

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
>