[PATCH next] fs: Replace strcpy(s, "../") with memcpy(s, "../", 4)

[PATCH next] fs: Replace strcpy(s, "../") with memcpy(s, "../", 4)

[david.laight.linux]

From: David Laight <david.laight.linux@gmail.com>

The code has already checked there is enough room.
Use memcpy() to avoid compiler warnings from possibly unbounded strcpy().

Signed-off-by: David Laight <david.laight.linux@gmail.com>
---
This is one of a group of patches that remove potentially unbounded
strcpy() calls.

They are mostly replaced by strscpy() or, when strlen() has just been
called, with memcpy() (usually including the '\0').

Calls with copy string literals into arrays are left unchanged.
They are safe and easily detected as such.

The changes were made by getting the compiler to detect the calls and
then fixing the code by hand.

Note that all the changes are only compile tested.

Some Makefiles were changed to allow files to contain strcpy().
As well as 'difficult to fix' files, this included 'show' functions
as they really need to use sysfs_emit() or seq_printf().

All the patches are being sent individually to avoid very long cc lists.
Apologies for the terse commit messages and likely unexpected tags.
(There are about 100 patches in total.)

 fs/configfs/symlink.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/configfs/symlink.c b/fs/configfs/symlink.c
index f3f79c67add5..9f36699e5922 100644
--- a/fs/configfs/symlink.c
+++ b/fs/configfs/symlink.c
@@ -67,7 +67,7 @@ static int configfs_get_target_path(struct config_item *item,
 	pr_debug("%s: depth = %d, size = %d\n", __func__, depth, size);
 
 	for (s = path; depth--; s += 3)
-		strcpy(s,"../");
+		memcpy(s, "../", 4);
 
 	fill_item_path(target, path, size);
 	pr_debug("%s: path = '%s'\n", __func__, path);
-- 
2.39.5

Re: [PATCH next] fs: Replace strcpy(s, "../") with memcpy(s, "../", 4)

[Andreas Hindborg]

<david.laight.linux@gmail.com> writes:

> From: David Laight <david.laight.linux@gmail.com>
>
> The code has already checked there is enough room.
> Use memcpy() to avoid compiler warnings from possibly unbounded strcpy().
>
> Signed-off-by: David Laight <david.laight.linux@gmail.com>
> ---
> This is one of a group of patches that remove potentially unbounded
> strcpy() calls.
>
> They are mostly replaced by strscpy() or, when strlen() has just been
> called, with memcpy() (usually including the '\0').
>
> Calls with copy string literals into arrays are left unchanged.
> They are safe and easily detected as such.
>
> The changes were made by getting the compiler to detect the calls and
> then fixing the code by hand.
>
> Note that all the changes are only compile tested.
>
> Some Makefiles were changed to allow files to contain strcpy().
> As well as 'difficult to fix' files, this included 'show' functions
> as they really need to use sysfs_emit() or seq_printf().
>
> All the patches are being sent individually to avoid very long cc lists.
> Apologies for the terse commit messages and likely unexpected tags.
> (There are about 100 patches in total.)
>
>  fs/configfs/symlink.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/fs/configfs/symlink.c b/fs/configfs/symlink.c
> index f3f79c67add5..9f36699e5922 100644
> --- a/fs/configfs/symlink.c
> +++ b/fs/configfs/symlink.c
> @@ -67,7 +67,7 @@ static int configfs_get_target_path(struct config_item *item,
>  	pr_debug("%s: depth = %d, size = %d\n", __func__, depth, size);
>
>  	for (s = path; depth--; s += 3)
> -		strcpy(s,"../");
> +		memcpy(s, "../", 4);

I don't think this transform makes sense when copying string literals.
The post transform code has one more foot gun than the original code.

Best regards,
Andreas Hindborg

Re: [PATCH next] fs: Replace strcpy(s, "../") with memcpy(s, "../", 4)

[David Laight]

On Fri, 19 Jun 2026 12:58:20 +0200
Andreas Hindborg <a.hindborg@kernel.org> wrote:

> <david.laight.linux@gmail.com> writes:
> 
> > From: David Laight <david.laight.linux@gmail.com>
> >
> > The code has already checked there is enough room.
> > Use memcpy() to avoid compiler warnings from possibly unbounded strcpy().
> >
> > Signed-off-by: David Laight <david.laight.linux@gmail.com>
> > ---
> > This is one of a group of patches that remove potentially unbounded
> > strcpy() calls.
> >
> > They are mostly replaced by strscpy() or, when strlen() has just been
> > called, with memcpy() (usually including the '\0').
> >
> > Calls with copy string literals into arrays are left unchanged.
> > They are safe and easily detected as such.
> >
> > The changes were made by getting the compiler to detect the calls and
> > then fixing the code by hand.
> >
> > Note that all the changes are only compile tested.
> >
> > Some Makefiles were changed to allow files to contain strcpy().
> > As well as 'difficult to fix' files, this included 'show' functions
> > as they really need to use sysfs_emit() or seq_printf().
> >
> > All the patches are being sent individually to avoid very long cc lists.
> > Apologies for the terse commit messages and likely unexpected tags.
> > (There are about 100 patches in total.)
> >
> >  fs/configfs/symlink.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/fs/configfs/symlink.c b/fs/configfs/symlink.c
> > index f3f79c67add5..9f36699e5922 100644
> > --- a/fs/configfs/symlink.c
> > +++ b/fs/configfs/symlink.c
> > @@ -67,7 +67,7 @@ static int configfs_get_target_path(struct config_item *item,
> >  	pr_debug("%s: depth = %d, size = %d\n", __func__, depth, size);
> >
> >  	for (s = path; depth--; s += 3)
> > -		strcpy(s,"../");
> > +		memcpy(s, "../", 4);  
> 
> I don't think this transform makes sense when copying string literals.
> The post transform code has one more foot gun than the original code.

They are actually identical, the compiler converts the former to the latter.

I was trying to remove all the strcpy() where the target isn't an array.
The initial check also only allowed string literals - but I relaxed that
a bit to reduce the number of false positives.
Were a similar check for calls to strcpy() be committed this code would
need changing, but you want something that ends up being a (misaligned)
32bit write of a constant on most architectures.  

I just looked at the code again, the final '- 1' on the 'size = ...'
line looks very odd.

I wonder if it would be simpler to merge all three functions into
something with a single loop that builds the name/name part backwards
from the end of the buffer while adding "../" on the front and then
calling memmove() to put the two together.

	David

> 
> Best regards,
> Andreas Hindborg
> 
> 
> 

Re: [PATCH next] fs: Replace strcpy(s, "../") with memcpy(s, "../", 4)

[Andreas Hindborg]

David Laight <david.laight.linux@gmail.com> writes:

> On Fri, 19 Jun 2026 12:58:20 +0200
> Andreas Hindborg <a.hindborg@kernel.org> wrote:
>
>> <david.laight.linux@gmail.com> writes:
>> 
>> > From: David Laight <david.laight.linux@gmail.com>
>> >
>> > The code has already checked there is enough room.
>> > Use memcpy() to avoid compiler warnings from possibly unbounded strcpy().
>> >
>> > Signed-off-by: David Laight <david.laight.linux@gmail.com>
>> > ---
>> > This is one of a group of patches that remove potentially unbounded
>> > strcpy() calls.
>> >
>> > They are mostly replaced by strscpy() or, when strlen() has just been
>> > called, with memcpy() (usually including the '\0').
>> >
>> > Calls with copy string literals into arrays are left unchanged.
>> > They are safe and easily detected as such.
>> >
>> > The changes were made by getting the compiler to detect the calls and
>> > then fixing the code by hand.
>> >
>> > Note that all the changes are only compile tested.
>> >
>> > Some Makefiles were changed to allow files to contain strcpy().
>> > As well as 'difficult to fix' files, this included 'show' functions
>> > as they really need to use sysfs_emit() or seq_printf().
>> >
>> > All the patches are being sent individually to avoid very long cc lists.
>> > Apologies for the terse commit messages and likely unexpected tags.
>> > (There are about 100 patches in total.)
>> >
>> >  fs/configfs/symlink.c | 2 +-
>> >  1 file changed, 1 insertion(+), 1 deletion(-)
>> >
>> > diff --git a/fs/configfs/symlink.c b/fs/configfs/symlink.c
>> > index f3f79c67add5..9f36699e5922 100644
>> > --- a/fs/configfs/symlink.c
>> > +++ b/fs/configfs/symlink.c
>> > @@ -67,7 +67,7 @@ static int configfs_get_target_path(struct config_item *item,
>> >  	pr_debug("%s: depth = %d, size = %d\n", __func__, depth, size);
>> >
>> >  	for (s = path; depth--; s += 3)
>> > -		strcpy(s,"../");
>> > +		memcpy(s, "../", 4);  
>> 
>> I don't think this transform makes sense when copying string literals.
>> The post transform code has one more foot gun than the original code.
>
> They are actually identical, the compiler converts the former to the latter.

The original one is resilient to changes in the string literal. The
transformed one has a risk of reading beyond the string if the string is
shortened without the length being updated. Or it can create a string
that is not null terminated if the string literal is made longer without
the constant changing.

> I was trying to remove all the strcpy() where the target isn't an array.
> The initial check also only allowed string literals - but I relaxed that
> a bit to reduce the number of false positives.
> Were a similar check for calls to strcpy() be committed this code would
> need changing, but you want something that ends up being a (misaligned)
> 32bit write of a constant on most architectures.  
>
> I just looked at the code again, the final '- 1' on the 'size = ...'
> line looks very odd.

It's to leave space for a null char at the end. `fill_item_path` writes
the path from the last segment to the first.

> I wonder if it would be simpler to merge all three functions into
> something with a single loop that builds the name/name part backwards
> from the end of the buffer while adding "../" on the front and then
> calling memmove() to put the two together.

The current implementation is difficult to read for sure. It would be
nice if we can make it more simple to parse.

Best regards,
Andreas Hindborg

Re: [PATCH next] fs: Replace strcpy(s, "../") with memcpy(s, "../", 4)

[David Laight]

On Mon, 22 Jun 2026 10:57:21 +0200
Andreas Hindborg <a.hindborg@kernel.org> wrote:

> David Laight <david.laight.linux@gmail.com> writes:
...
> > I just looked at the code again, the final '- 1' on the 'size = ...'
> > line looks very odd.  
> 
> It's to leave space for a null char at the end. `fill_item_path` writes
> the path from the last segment to the first.

But wouldn't that be a '+ 1' ?
It might be alright because (IIRC) the length is initialised to one
in the helper function.

> 
> > I wonder if it would be simpler to merge all three functions into
> > something with a single loop that builds the name/name part backwards
> > from the end of the buffer while adding "../" on the front and then
> > calling memmove() to put the two together.  
> 
> The current implementation is difficult to read for sure. It would be
> nice if we can make it more simple to parse.

I dislike code that does two passes, one to work out the size and the
second to do the work. All too easy for them to get out of sync.

One of the pathname functions (but I don't know if this code is used for it)
lets the string start part way down the supplied buffer.
If it is that case then it could be a lot simpler.

It also wouldn't do any hard to try embedding the 'char name[PATH_MAX]'
in a structure - so the size is passed implicitly and the compiler can
check and humans know what they can do.

	David



> 
> Best regards,
> Andreas Hindborg
>