From: sashiko-bot@kernel.org
To: "Masami Hiramatsu (Google)" <mhiramat@kernel.org>
Cc: linux-trace-kernel@vger.kernel.org
Subject: Re: [PATCH v2 1/2] tracing: Override the same name trace_instance= by latter one
Date: Fri, 02 Oct 2026 09:14:31 +0000 [thread overview]
Message-ID: <20261002091431.DD73F1F000FF@smtp.kernel.org> (raw)
In-Reply-To: <179091985884.537422.15845141877166136300.stgit@devnote2>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] tracing: heap out-of-bounds write in parse_boot_instance_info due to unescaped tabs
- [Medium] tracing: duplicate trace array creation via implicit backup lookup causes tracefs init failure
--
commit e7d9ac9646a2e104af11665c8c61543d20737c13
Author: Masami Hiramatsu (Google) <mhiramat@kernel.org>
tracing: Override the same name trace_instance= by latter one
Override the same name boot instance by the latter parameter.
This allows user to override the trace instance in bootconfig by the
cmdline from bootloader.
> diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
> index e4a490d3d08c8..4590d38969450 100644
> --- a/kernel/trace/trace.c
> +++ b/kernel/trace/trace.c
> @@ -308,6 +309,7 @@ static int __init boot_instance(char *str)
>
> ret = snprintf(slot, left, "%s\t", str);
> boot_instance_index += ret;
> + nr_boot_instances++;
>
> return 1;
> }
[ ... ]
> +__init static void parse_boot_instance_info(struct boot_instance *boot_instances)
> {
[ ... ]
> + while ((events = strsep(&str, "\t"))) {
> + if (!*events)
> + continue;
[ ... ]
> + for (i = 0; i < idx; i++) {
> + /* Override by the last defined instance */
> + if (!strcmp(name, boot_instances[i].name))
> + break;
> }
>
> + boot_instances[i].name = name;
> + boot_instances[i].flag_delim = flag_delim;
> + boot_instances[i].addr_delim = addr_delim;
> + boot_instances[i].backup = backup;
> + boot_instances[i].events = events;
[Severity: High]
If a user provides a quoted parameter containing a literal tab (for example,
trace_instance="foo\tbar"), won't strsep(&str, "\t") split it into more tokens
than what was originally counted in nr_boot_instances?
This loop appears to write beyond the bounds of the boot_instances array when
there are embedded tabs, which could lead to memory corruption and a kernel
panic during early boot.
> + if (i == idx)
> + idx++;
> + }
> +
> + nr_boot_instances = idx;
> +}
> +
> +__init static void enable_instances(void)
> +{
> + struct boot_instance *boot_instances __free(kfree) = NULL;
> + struct boot_instance *bi;
> + struct trace_array *tr;
> + bool memmap_area = false;
> + char *tok;
> +
> + if (!boot_instance_index)
> + return;
> +
> + /* Parse the instance name to check the overlap */
> + boot_instances = kmalloc_array(nr_boot_instances,
> + sizeof(*boot_instances), GFP_KERNEL);
> + if (!boot_instances)
> + return;
> +
> + parse_boot_instance_info(boot_instances);
> +
> + for (int i = 0; i < nr_boot_instances; i++) {
> + char *rname __free(kfree) = NULL;
[ ... ]
> - if (trace_array_find(name)) {
> - pr_warn("Tracing: Instance %s already exists\n", name);
> - continue;
> - }
> -
> - if (backup) {
> - if (backup_instance_area(backup, &addr, &size) < 0)
> + if (bi->backup) {
> + if (backup_instance_area(bi->backup, &addr, &size) < 0)
> continue;
> }
[ ... ]
> - tr = trace_array_create_systems(name, NULL, addr, size);
> + tr = trace_array_create_systems(bi->name, NULL, addr, size);
[Severity: Medium]
With the trace_array_find() check removed, does this unconditionally create a
new trace array, even if one implicitly exists?
If a user specifies a trace_instance with a backup pointing to another instance
defined later (e.g., trace_instance=foo=bar trace_instance=bar),
backup_instance_area() will implicitly create "bar" via
trace_array_get_by_name().
When the loop processes "bar" explicitly later on, it seems this code will call
trace_array_create_systems("bar", ...) a second time, duplicating the trace
array in ftrace_trace_arrays. This duplicate could cause tracefs_create_dir()
to fail and abort initialization of subsequent trace instances.
--
Sashiko AI review · https://sashiko.dev/#/patchset/179091984881.537422.15308457677039592540.stgit@devnote2?part=1
next prev parent reply other threads:[~2026-10-02 9:14 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-02 5:44 [PATCH v2 0/2] tracing: Override trace_instance parameter Masami Hiramatsu (Google)
2026-10-02 5:44 ` [PATCH v2 1/2] tracing: Override the same name trace_instance= by latter one Masami Hiramatsu (Google)
2026-10-02 9:14 ` sashiko-bot [this message]
2026-10-02 10:46 ` Masami Hiramatsu (Google)
2026-10-02 5:44 ` [PATCH v2 2/2] selftests/ftrace: Add test case for overriding trace_instance parameter Masami Hiramatsu (Google)
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=20261002091431.DD73F1F000FF@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=linux-trace-kernel@vger.kernel.org \
--cc=mhiramat@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox