[PATCH] fanotify: replace deprecated strcpy in fanotify_info_copy_{name,name2}

[PATCH] fanotify: replace deprecated strcpy in fanotify_info_copy_{name,name2}

[Thorsten Blum]

strcpy() has been deprecated [1] because it performs no bounds checking
on the destination buffer, which can lead to buffer overflows. Replace
it with the safer strscpy().

Link: https://www.kernel.org/doc/html/latest/process/deprecated.html#strcpy [1]
Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev>
---
 fs/notify/fanotify/fanotify.h | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/fs/notify/fanotify/fanotify.h b/fs/notify/fanotify/fanotify.h
index 39e60218df7c..a0619e7694d5 100644
--- a/fs/notify/fanotify/fanotify.h
+++ b/fs/notify/fanotify/fanotify.h
@@ -2,6 +2,7 @@
 #include <linux/fsnotify_backend.h>
 #include <linux/path.h>
 #include <linux/slab.h>
+#include <linux/string.h>
 #include <linux/exportfs.h>
 #include <linux/hashtable.h>
 
@@ -218,7 +219,7 @@ static inline void fanotify_info_copy_name(struct fanotify_info *info,
 		return;
 
 	info->name_len = name->len;
-	strcpy(fanotify_info_name(info), name->name);
+	strscpy(fanotify_info_name(info), name->name, name->len + 1);
 }
 
 static inline void fanotify_info_copy_name2(struct fanotify_info *info,
@@ -228,7 +229,7 @@ static inline void fanotify_info_copy_name2(struct fanotify_info *info,
 		return;
 
 	info->name2_len = name->len;
-	strcpy(fanotify_info_name2(info), name->name);
+	strscpy(fanotify_info_name2(info), name->name, name->len + 1);
 }
 
 /*

Re: [PATCH] fanotify: replace deprecated strcpy in fanotify_info_copy_{name,name2}

[Jan Kara]

On Sat 21-03-26 22:05:47, Thorsten Blum wrote:
> strcpy() has been deprecated [1] because it performs no bounds checking
> on the destination buffer, which can lead to buffer overflows. Replace
> it with the safer strscpy().
> 
> Link: https://www.kernel.org/doc/html/latest/process/deprecated.html#strcpy [1]
> Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev>

I was a bit undecided about this one because I was wondering what
additional protection does the use of strscpy() bring here. But I guess the
protection from corrupted qstr (where the length doesn't match the real string
length) makes some sense. So I've taken the patch into my tree. Thanks!

								Honza

> ---
>  fs/notify/fanotify/fanotify.h | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/fs/notify/fanotify/fanotify.h b/fs/notify/fanotify/fanotify.h
> index 39e60218df7c..a0619e7694d5 100644
> --- a/fs/notify/fanotify/fanotify.h
> +++ b/fs/notify/fanotify/fanotify.h
> @@ -2,6 +2,7 @@
>  #include <linux/fsnotify_backend.h>
>  #include <linux/path.h>
>  #include <linux/slab.h>
> +#include <linux/string.h>
>  #include <linux/exportfs.h>
>  #include <linux/hashtable.h>
>  
> @@ -218,7 +219,7 @@ static inline void fanotify_info_copy_name(struct fanotify_info *info,
>  		return;
>  
>  	info->name_len = name->len;
> -	strcpy(fanotify_info_name(info), name->name);
> +	strscpy(fanotify_info_name(info), name->name, name->len + 1);
>  }
>  
>  static inline void fanotify_info_copy_name2(struct fanotify_info *info,
> @@ -228,7 +229,7 @@ static inline void fanotify_info_copy_name2(struct fanotify_info *info,
>  		return;
>  
>  	info->name2_len = name->len;
> -	strcpy(fanotify_info_name2(info), name->name);
> +	strscpy(fanotify_info_name2(info), name->name, name->len + 1);
>  }
>  
>  /*
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR

Re: [PATCH] fanotify: replace deprecated strcpy in fanotify_info_copy_{name,name2}

[Christian Brauner]

On Mon, Mar 23, 2026 at 10:14:24AM +0100, Jan Kara wrote:
> On Sat 21-03-26 22:05:47, Thorsten Blum wrote:
> > strcpy() has been deprecated [1] because it performs no bounds checking
> > on the destination buffer, which can lead to buffer overflows. Replace
> > it with the safer strscpy().
> > 
> > Link: https://www.kernel.org/doc/html/latest/process/deprecated.html#strcpy [1]
> > Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev>
> 
> I was a bit undecided about this one because I was wondering what
> additional protection does the use of strscpy() bring here. But I guess the
> protection from corrupted qstr (where the length doesn't match the real string
> length) makes some sense. So I've taken the patch into my tree. Thanks!

Fwiw, patches are now auto-tested on vfs-ci:
https://github.com/linux-fsdevel/vfs/pull/860
Just for some testing data. We should probably hook up the relevant LTP
tests for fanotify there as well.

Re: [PATCH] fanotify: replace deprecated strcpy in fanotify_info_copy_{name,name2}

[Amir Goldstein]

On Mon, Mar 23, 2026 at 11:12 AM Christian Brauner <brauner@kernel.org> wrote:
>
> On Mon, Mar 23, 2026 at 10:14:24AM +0100, Jan Kara wrote:
> > On Sat 21-03-26 22:05:47, Thorsten Blum wrote:
> > > strcpy() has been deprecated [1] because it performs no bounds checking
> > > on the destination buffer, which can lead to buffer overflows. Replace
> > > it with the safer strscpy().
> > >
> > > Link: https://www.kernel.org/doc/html/latest/process/deprecated.html#strcpy [1]
> > > Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev>
> >
> > I was a bit undecided about this one because I was wondering what
> > additional protection does the use of strscpy() bring here. But I guess the
> > protection from corrupted qstr (where the length doesn't match the real string
> > length) makes some sense. So I've taken the patch into my tree. Thanks!
>
> Fwiw, patches are now auto-tested on vfs-ci:
> https://github.com/linux-fsdevel/vfs/pull/860
> Just for some testing data. We should probably hook up the relevant LTP
> tests for fanotify there as well.

That would be cool :)

I guess for vfs you would would to run these LTP test groups
$ ls runtest/fs*
runtest/fs  runtest/fs_bind  runtest/fs_perms_simple  runtest/fs_readonly

fanotify tests are currently only in the syscalls group.

I could create an fsnotify test group or
we could try to create a vfs focused group such as fs_syscalls,
but actually, at a quick glance, it looks like ~75% are fs related syscalls.

Thanks,
Amir.

Re: [PATCH] fanotify: replace deprecated strcpy in fanotify_info_copy_{name,name2}

[Jan Kara]

On Mon 23-03-26 12:00:27, Amir Goldstein wrote:
> On Mon, Mar 23, 2026 at 11:12 AM Christian Brauner <brauner@kernel.org> wrote:
> >
> > On Mon, Mar 23, 2026 at 10:14:24AM +0100, Jan Kara wrote:
> > > On Sat 21-03-26 22:05:47, Thorsten Blum wrote:
> > > > strcpy() has been deprecated [1] because it performs no bounds checking
> > > > on the destination buffer, which can lead to buffer overflows. Replace
> > > > it with the safer strscpy().
> > > >
> > > > Link: https://www.kernel.org/doc/html/latest/process/deprecated.html#strcpy [1]
> > > > Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev>
> > >
> > > I was a bit undecided about this one because I was wondering what
> > > additional protection does the use of strscpy() bring here. But I guess the
> > > protection from corrupted qstr (where the length doesn't match the real string
> > > length) makes some sense. So I've taken the patch into my tree. Thanks!
> >
> > Fwiw, patches are now auto-tested on vfs-ci:
> > https://github.com/linux-fsdevel/vfs/pull/860
> > Just for some testing data. We should probably hook up the relevant LTP
> > tests for fanotify there as well.
> 
> That would be cool :)
> 
> I guess for vfs you would would to run these LTP test groups
> $ ls runtest/fs*
> runtest/fs  runtest/fs_bind  runtest/fs_perms_simple  runtest/fs_readonly
> 
> fanotify tests are currently only in the syscalls group.
> 
> I could create an fsnotify test group or
> we could try to create a vfs focused group such as fs_syscalls,
> but actually, at a quick glance, it looks like ~75% are fs related syscalls.

Some of the LTP tests do take noticeable amount of time so I'm not sure if
we want to run all of them for each commit. Ideally tests would be selected
based on modified code but maybe that's a bit of overengineering (but it
might be an interesting project for AI to write a script that based on gcov
data outputs a set of tests to run for given patch :)).

								Honza
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR