strncpy() is deprecated for use on NUL-terminated destination strings [1] and
as such we should prefer more robust and less ambiguous string interfaces.

We expect the @pattern and @num_buf strings to be NUL-terminated, as
evidenced by their manual NUL-byte assignments immediately following
each copy.

Switch to using strscpy which guarantees NUL-termination for the
destination buffer -- eschewing manual NUL-byte assignments. strscpy
does not NUL-pad so to keep this behavior zero-allocate @num_buf. @pred
is already zero-allocated before the copies.
	pred = kzalloc(sizeof(*pred), GFP_KERNEL);

This should result in no behavioral changes whilst helping towards the
goal of [2] -- with the ultimate goal of removing strncpy in favor of
less ambiguous and more robust alternatives.

Link: https://www.kernel.org/doc/html/latest/process/deprecated.html#strncpy-on-nul-terminated-strings [1]
Link: https://github.com/KSPP/linux/issues/90 [2]
Link: https://manpages.debian.org/testing/linux-manual-4.8/strscpy.9.en.html
Cc: Kees Cook <keescook@chromium.org>
Cc: linux-hardening@vger.kernel.org
Signed-off-by: Justin Stitt <justinstitt@google.com>
---
 kernel/trace/trace_events_filter.c | 14 +++++---------
 1 file changed, 5 insertions(+), 9 deletions(-)

diff --git a/kernel/trace/trace_events_filter.c b/kernel/trace/trace_events_filter.c
index 0c611b281a5b..76b55eead8ac 100644
--- a/kernel/trace/trace_events_filter.c
+++ b/kernel/trace/trace_events_filter.c
@@ -1506,7 +1506,7 @@ static int parse_pred(const char *str, void *data,
 	unsigned long offset;
 	unsigned long size;
 	unsigned long ip;
-	char num_buf[24];	/* Big enough to hold an address */
+	char num_buf[24] = {0};	/* Big enough to hold an address */
 	char *field_name;
 	char *name;
 	bool function = false;
@@ -1616,8 +1616,7 @@ static int parse_pred(const char *str, void *data,
 				goto err_free;
 			}
 
-			strncpy(num_buf, str + s, len);
-			num_buf[len] = 0;
+			strscpy(num_buf, str + s, len);
 
 			ret = kstrtoul(num_buf, 0, &ip);
 			if (ret) {
@@ -1694,8 +1693,7 @@ static int parse_pred(const char *str, void *data,
 		if (!pred->regex)
 			goto err_mem;
 		pred->regex->len = len;
-		strncpy(pred->regex->pattern, str + s, len);
-		pred->regex->pattern[len] = 0;
+		strscpy(pred->regex->pattern, str + s, len);
 
 	} else if (!strncmp(str + i, "CPUS", 4)) {
 		unsigned int maskstart;
@@ -1859,8 +1857,7 @@ static int parse_pred(const char *str, void *data,
 		if (!pred->regex)
 			goto err_mem;
 		pred->regex->len = len;
-		strncpy(pred->regex->pattern, str + s, len);
-		pred->regex->pattern[len] = 0;
+		strscpy(pred->regex->pattern, str + s, len);
 
 		filter_build_regex(pred);
 
@@ -1919,8 +1916,7 @@ static int parse_pred(const char *str, void *data,
 			goto err_free;
 		}
 
-		strncpy(num_buf, str + s, len);
-		num_buf[len] = 0;
+		strscpy(num_buf, str + s, len);
 
 		/* Make sure it is a value */
 		if (field->is_signed)

---
base-commit: bc83b4d1f08695e85e85d36f7b803da58010161d
change-id: 20240930-strncpy-kernel-trace-trace_events_filter-c-f44a3f848518

Best regards,
--
Justin Stitt <justinstitt@google.com>

On Mon, 30 Sep 2024 17:03:45 -0700
Justin Stitt <justinstitt@google.com> wrote:

> strncpy() is deprecated for use on NUL-terminated destination strings [1] and
> as such we should prefer more robust and less ambiguous string interfaces.
> 
> We expect the @pattern and @num_buf strings to be NUL-terminated, as
> evidenced by their manual NUL-byte assignments immediately following
> each copy.
> 
> Switch to using strscpy which guarantees NUL-termination for the
> destination buffer -- eschewing manual NUL-byte assignments. strscpy
> does not NUL-pad so to keep this behavior zero-allocate @num_buf. @pred
> is already zero-allocated before the copies.
> 	pred = kzalloc(sizeof(*pred), GFP_KERNEL);
> 
> This should result in no behavioral changes whilst helping towards the
> goal of [2] -- with the ultimate goal of removing strncpy in favor of
> less ambiguous and more robust alternatives.
> 
> Link: https://www.kernel.org/doc/html/latest/process/deprecated.html#strncpy-on-nul-terminated-strings [1]
> Link: https://github.com/KSPP/linux/issues/90 [2]
> Link: https://manpages.debian.org/testing/linux-manual-4.8/strscpy.9.en.html
> Cc: Kees Cook <keescook@chromium.org>
> Cc: linux-hardening@vger.kernel.org
> Signed-off-by: Justin Stitt <justinstitt@google.com>

So this breaks my tests. This is why I have trouble with taking changes
like this :-(

Before this patch, his worked:

 # echo 'common_pid != 0 && common_pid != 120 && common_pid != 1253 && common_pid != 17 && common_pid != 394 && common_pid != 81 && common_pid != 87' > /sys/kernel/tracing/events/sched/sched_switch/filter

But now it gives an error of:

 -bash: echo: write error: Invalid argument

I have to drop this.

-- Steve

On Tue, Oct 8, 2024 at 6:13 PM Steven Rostedt <rostedt@goodmis.org> wrote:
>
> So this breaks my tests. This is why I have trouble with taking changes
> like this :-(

Shoot.

I think deprecated API cleanups are important but creating more bugs
in the process is not helping anybody. I dropped the ball here... my
patch has an off-by-one.

>
> Before this patch, his worked:
>
>  # echo 'common_pid != 0 && common_pid != 120 && common_pid != 1253 && common_pid != 17 && common_pid != 394 && common_pid != 81 && common_pid != 87' > /sys/kernel/tracing/events/sched/sched_switch/filter

Thanks for providing the test case, this made triaging dead simple.

>
> But now it gives an error of:
>
>  -bash: echo: write error: Invalid argument
>
> I have to drop this.

In many cases where folks are doing 1) strncpy and 2) manual NUL-byte
assignment, the clear replacement is strscpy. However most of those
cases look like this:

  strncpy(dst, src, len);
  dst[len-1] = '\0';

and this case was just

  strncpy(dst, src, len);
  dst[len] = '\0';

Since we have an explicit size check before the first copy, ensuring
@len doesn't overflow @dst, this code is fine but I missed the
off-by-one.

So, assuming I haven't lost your faith, I can send a v2 along the lines of:

1)
  strscpy(num_buf, str + s, len + 1);

  ... or
2)
  memcpy(num_buf, str + s, len);
  num_buf[len] = 0;

And if you're wondering about option 3: "Don't change anything because
the code works". I'd reiterate that I think it's important to replace
bad ambiguous APIs. There are many cases where folks use strncpy() as
a glorified memcpy because they want the padding behavior, or they use
it on non-null terminated destinations or tons of other "misuses".
Ambiguous code like that poses a real danger to the maintainability of
the codebase and opens threat vectors.

>
> -- Steve

Thanks
Justin

On Fri, 11 Oct 2024 14:59:16 -0700
Justin Stitt <justinstitt@google.com> wrote:

> So, assuming I haven't lost your faith, I can send a v2 along the lines of:

Not yet ;-)

> 
> 1)
>   strscpy(num_buf, str + s, len + 1);
> 
>   ... or
> 2)
>   memcpy(num_buf, str + s, len);
>   num_buf[len] = 0;
> 
> And if you're wondering about option 3: "Don't change anything because
> the code works". I'd reiterate that I think it's important to replace
> bad ambiguous APIs. There are many cases where folks use strncpy() as
> a glorified memcpy because they want the padding behavior, or they use
> it on non-null terminated destinations or tons of other "misuses".
> Ambiguous code like that poses a real danger to the maintainability of
> the codebase and opens threat vectors.

I use it as a string memcpy, where it doesn't copy more than source. But I
don't care about the padding. So option 2 is fine with me.

-- Steve