All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "David Carlier" <devnexen@gmail.com>
Cc: linux-trace-kernel@vger.kernel.org
Subject: Re: [PATCH] tracing: Reject .function on the function trace event
Date: Sat, 14 Nov 2026 20:12:37 +0000	[thread overview]
Message-ID: <sashiko-outbox-214993@kernel.org> (raw)
In-Reply-To: <20261114195914.2678414-1-devnexen@gmail.com>

Thank you for your contribution! Sashiko AI review found no new issues
in this patch, but noticed 1 related pre-existing issue it does not
introduce:
- [Critical] tracing: out-of-bounds read in parse_pred() on empty
  function filter operand [1]
--

commit e67c952556cf8df0fc74a91895fdbea1c0dd54b5
Author: David Carlier <devnexen@gmail.com>

tracing: Reject .function on the function trace event

This commit rejects the .function filter suffix on the function trace
event so that parse_pred() does not build a predicate with a NULL regex.

> diff --git a/kernel/trace/trace_events_filter.c b/kernel/trace/trace_events_filter.c
> index 5e74d2dae40a3..9c807191166ba 100644
> --- a/kernel/trace/trace_events_filter.c
> +++ b/kernel/trace/trace_events_filter.c
> @@ -1744,6 +1744,12 @@ static int parse_pred(const char *str, void *data,
>  	pred->op = op;
>  
>  	if (function) {
> +		/* Function events already take a function name on 'ip' */
> +		if (ftrace_event_is_function(call)) {
> +			parse_error(pe, FILT_ERR_ILLEGAL_FIELD_OP, pos + i);
> +			goto err_free;
> +		}
> +
>  		/* The field must be the same size as long */
>  		if (field->size != sizeof(long)) {
>  			parse_error(pe, FILT_ERR_ILLEGAL_FIELD_OP, pos + i);

[Severity: Critical]
This problem wasn't introduced by this patch, but can the paired
ftrace_event_is_function(call) branch in parse_pred() read past the end
of str [1] when the filter has no operand after the operator (for
example, "ip ==")?

kernel/trace/trace_events_filter.c:parse_pred() {
	...
	} else if (ftrace_event_is_function(call)) {
		...
		if (str[i] == '\'' || str[i] == '"')
			q = str[i];
		else
			q = 0;

		for (i++; str[i]; i++) {
	...
}

When str ends after the operator and optional whitespace, str[i] is the
terminating NUL byte and q is set to 0.  The loop initializer i++ then
advances i one byte past the NUL terminator before checking str[i], so
parse_pred() scans out-of-bounds slab memory, copies it into
pred->regex->pattern, and returns the out-of-bounds offset to
predicate_parse().

[1] https://sashiko.dev/#/bug/linux-911099f1-cea5-4f84-ba41-25fbcbb66dad

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261114195914.2678414-1-devnexen@gmail.com?part=1

      reply	other threads:[~2026-11-14 20:12 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-14 19:59 [PATCH] tracing: Reject .function on the function trace event David Carlier
2026-11-14 20:12 ` sashiko-bot [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=sashiko-outbox-214993@kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=devnexen@gmail.com \
    --cc=linux-trace-kernel@vger.kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.