Re: [PATCH 01/10] tracing/filters: Fix MATCH_END_ONLY regex matching for fixed-size strings

[Masami Hiramatsu (Google)]

On Mon, 26 Oct 2026 09:54:41 -0400, Steven Rostedt <rostedt@xxxxxxxxxxx> wrote:
> On Sun, 25 Oct 2026 01:25:33 +0900
> "Masami Hiramatsu (Google)" <mhiramat@xxxxxxxxxx> wrote:
> 
> > From: Masami Hiramatsu (Google) <mhiramat@xxxxxxxxxx>
> > 
> > regex_match_end() calculated string length as "len - 1", assuming @len is
> > the string length including trailing '\0'. However, for fixed-size string
> > fields, filter_pred_string() passes field->size as @len, and for "comm",
> > filter_pred_comm() passes TASK_COMM_LEN as @len.
> > 
> > Because @len in these cases represents the buffer capacity rather than the
> > actual length of the string, regex_match_end() tests against the tail of
> > the buffer (typically trailing '\0' padding) rather than the end of the
> > string. Furthermore, if @len is 0 (denoting a dynamic string ending with
> > '\0'), "len - 1" underflows to -1 and never matches.
> > 
> > Compute the actual string length using strnlen(str, len) when @len is
> > non-zero, and strlen(str) when @len is zero.
> > 
> > Fixes: a3291c14ecf0 ("tracing/filters: Fix MATCH_END_ONLY filter matching")
> > Cc: stable@xxxxxxxxxxxxxxx
> > Signed-off-by: Masami Hiramatsu (Google) <mhiramat@xxxxxxxxxx>
> > ---
> >  kernel/trace/trace_events_filter.c |    6 +++---
> >  1 file changed, 3 insertions(+), 3 deletions(-)
> > 
> > diff --git a/kernel/trace/trace_events_filter.c b/kernel/trace/trace_events_filter.c
> > index 5e74d2dae40a..18ce3ec00d34 100644
> > --- a/kernel/trace/trace_events_filter.c
> > +++ b/kernel/trace/trace_events_filter.c
> > @@ -1075,10 +1075,10 @@ static int regex_match_middle(char *str, struct regex *r, int len)
> >  
> >  static int regex_match_end(char *str, struct regex *r, int len)
> >  {
> > -	int strlen = len - 1;
> > +	int slen = len ? strnlen(str, len) : strlen(str);
> >  
> > -	if (strlen >= r->len &&
> > -	    memcmp(str + strlen - r->len, r->pattern, r->len) == 0)
> > +	if (slen >= r->len &&
> > +	    memcmp(str + slen - r->len, r->pattern, r->len) == 0)
> >  		return 1;
> 
> This slows down the code as it adds more strlen() calculations (it could
> have already been done.

I sent v2 already, which is slightly lighter (but still using strnlen)

https://lore.kernel.org/all/179291743946.492959.9624495647021680807.stgit@devnote2/

(anyway, 3/10 is already fixed as Sashiko mentioned.)

> 
> Let's fix the callers instead and have them pass in the real length.

OK, let me check it.

Thanks,

-- 
Masami Hiramatsu (Google) <mhiramat@xxxxxxxxxx>