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
prev parent 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.