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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20250523133100.1b023a6e@pumpkin>
Date: Fri, 23 May 2025 13:31:00 +0100
From: David Laight <david.laight.linux@...il.com>
To: "Theodore Ts'o" <tytso@....edu>
Cc: Kees Cook <kees@...nel.org>, Ethan Carter Edwards
 <ethan@...ancedwards.com>, Andreas Dilger <adilger.kernel@...ger.ca>,
 linux-ext4@...r.kernel.org, linux-kernel@...r.kernel.org,
 linux-hardening@...r.kernel.org
Subject: Re: [PATCH v2] ext4: replace strcpy() with '.' assignment

On Mon, 19 May 2025 10:59:30 -0400
"Theodore Ts'o" <tytso@....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
>