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
| ||
|
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 >
Powered by blists - more mailing lists