| Message ID | 20240930-strncpy-kernel-trace-trace_events_filter-c-v1-1-feed30820b83@google.com (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | tracing: replace multiple deprecated strncpy with strscpy | expand |
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
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)
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(-) --- base-commit: bc83b4d1f08695e85e85d36f7b803da58010161d change-id: 20240930-strncpy-kernel-trace-trace_events_filter-c-f44a3f848518 Best regards, -- Justin Stitt <justinstitt@google.com>