Re: [PATCH v2] ext4: replace strcpy() with '.' assignment

[David Laight <david.laight.linux@gmail.com>]

On Mon, 19 May 2025 10:59:30 -0400
"Theodore Ts'o" <tytso@mit.edu> wrote:

> On Mon, May 19, 2025 at 06:52:13AM -0700, Kees Cook wrote:
> > > --- a/fs/ext4/inline.c
> > > +++ b/fs/ext4/inline.c
> > > @@ -1314,7 +1314,7 @@ int ext4_inlinedir_to_tree(struct file *dir_file,
> > >  		if (pos == 0) {
> > >  			fake.inode = cpu_to_le32(inode->i_ino);
> > >  			fake.name_len = 1;
> > > -			strcpy(fake.name, ".");
> > > +			fake.name[0] = ".";  
> > 
> > This means the trailing NUL byte isn't being copied any more? That seems
> > like a big change, even if name_len is being used for length tracking.  
> 
> Yeah, and so that's something that needs to be tested (and not just
> build tested to catch the obvious FTBFS bug).

The compiler (or headers files) can also allow strcpy() of constant
length strings into arrays (known size). Erroring requests that are too long.
The strcpy() is then converted to a memcpy() which can then be optimised
into writes of constants.

So using strcpy() under those conditions 'isn't all bad' and can generate
better (and less bug prone) code than trying to hand-optimise it.

So even through strcpy() is usually a bad idea, there is not need to
remove the calls that the compiler can validate as safe.

	David   

> However, note how we
> handle normal filenames, as opposed to "." and "..".  From
> ext4_insert_dentry():
> 
> 	de->inode = cpu_to_le32(inode->i_ino);
> 	ext4_set_de_type(inode->i_sb, de, inode->i_mode);
> 	de->name_len = fname_len(fname);
> 	memcpy(de->name, fname_name(fname), fname_len(fname));
> 
> Or were you commenting on the "no functional changes intended" line in
> the commit description?  I agree that this is probably no longer
> accurate.  :-)
> 
> 					- Ted
>