[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250519145930.GB38098@mit.edu>
Date: Mon, 19 May 2025 10:59:30 -0400
From: "Theodore Ts'o" <tytso@....edu>
To: Kees Cook <kees@...nel.org>
Cc: 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, 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). 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