From: "Masami Hiramatsu (Google)" <mhiramat@kernel.org>
To: Steven Rostedt <rostedt@goodmis.org>,
Masami Hiramatsu <mhiramat@kernel.org>,
Shuah Khan <shuah@kernel.org>
Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
linux-kernel@vger.kernel.org, linux-trace-kernel@vger.kernel.org,
linux-kselftest@vger.kernel.org
Subject: [PATCH 03/10] tracing/filters: Check CPU bounds before cpumask_test_cpu() in do_filter_cpumask_scalar()
Date: Sun, 25 Oct 2026 01:25:52 +0900 [thread overview]
Message-ID: <179285915196.466249.7067056297377577459.stgit@devnote2> (raw)
In-Reply-To: <179285912318.466249.7425922682086130057.stgit@devnote2>
From: Masami Hiramatsu (Google) <mhiramat@kernel.org>
In parse_pred(), single-CPU cpumask filters are parsed via cpulist_parse(),
which checks against nr_cpumask_bits (NR_CPUS). When NR_CPUS > nr_cpu_ids,
a user can provide a CPU number where cpu >= nr_cpu_ids.
When evaluating such a predicate in filter_pred_cpumask_cpu(),
do_filter_cpumask_scalar() calls cpumask_test_cpu(cpu, mask) without
checking cpu against nr_cpu_ids. This triggers a WARN_ON_ONCE under
CONFIG_DEBUG_PER_CPU_MAPS and causes an out-of-bounds bit test.
Check "cpu >= nr_cpu_ids" at the start of do_filter_cpumask_scalar(). When
the CPU index is out of bounds, return "op == OP_NE" since an out-of-range
CPU is never present in a valid cpumask.
Fixes: 38c6f6808389 ("tracing/filters: Further optimise scalar vs cpumask comparison")
Cc: stable@vger.kernel.org
Signed-off-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
---
kernel/trace/trace_events_filter.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/kernel/trace/trace_events_filter.c b/kernel/trace/trace_events_filter.c
index c2c35b4de85e..69da95f42541 100644
--- a/kernel/trace/trace_events_filter.c
+++ b/kernel/trace/trace_events_filter.c
@@ -695,6 +695,9 @@ do_filter_scalar_cpumask(int op, unsigned int cpu, const struct cpumask *mask)
static inline int
do_filter_cpumask_scalar(int op, const struct cpumask *mask, unsigned int cpu)
{
+ if (cpu >= nr_cpu_ids)
+ return op == OP_NE;
+
switch (op) {
case OP_EQ:
return cpumask_test_cpu(cpu, mask) &&
next prev parent reply other threads:[~2026-10-24 16:25 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-24 16:25 [PATCH 00/10] tracing/filters: Fix event filter parsing and matching bugs Masami Hiramatsu (Google)
2026-10-24 16:25 ` [PATCH 01/10] tracing/filters: Fix MATCH_END_ONLY regex matching for fixed-size strings Masami Hiramatsu (Google)
2026-10-24 17:02 ` sashiko-bot
2026-10-25 2:11 ` Masami Hiramatsu
2026-10-26 13:54 ` Steven Rostedt
2026-10-26 15:37 ` Masami Hiramatsu (Google)
2026-10-24 16:25 ` [PATCH 02/10] tracing/filters: Fix false success return in process_system_preds() Masami Hiramatsu (Google)
2026-10-26 19:33 ` Steven Rostedt
2026-10-24 16:25 ` Masami Hiramatsu (Google) [this message]
2026-10-24 17:04 ` [PATCH 03/10] tracing/filters: Check CPU bounds before cpumask_test_cpu() in do_filter_cpumask_scalar() sashiko-bot
2026-10-26 19:36 ` Steven Rostedt
2026-10-24 16:26 ` [PATCH 04/10] tracing/filters: Handle out-of-range CPU for OP_NE in cpumask comparison Masami Hiramatsu (Google)
2026-10-26 19:38 ` Steven Rostedt
2026-10-24 16:26 ` [PATCH 05/10] tracing/filters: Report parse error on all -EINVAL paths in filter parsing Masami Hiramatsu (Google)
2026-10-26 19:40 ` Steven Rostedt
2026-10-24 16:26 ` [PATCH 06/10] tracing/filters: Fix function event operand parsing in parse_pred() Masami Hiramatsu (Google)
2026-10-24 16:26 ` [PATCH 07/10] tracing/filters: Skip second character of '&&' and '||' in calc_stack() Masami Hiramatsu (Google)
2026-10-24 16:26 ` [PATCH 08/10] tracing/filters: Reject unsupported field sizes in parse_pred() Masami Hiramatsu (Google)
2026-10-24 16:26 ` [PATCH 09/10] tracing/filters: Terminate filter string at first newline Masami Hiramatsu (Google)
2026-10-24 16:26 ` [PATCH 10/10] selftests/ftrace: Add event filter syntax check test case Masami Hiramatsu (Google)
2026-10-26 13:44 ` [PATCH 00/10] tracing/filters: Fix event filter parsing and matching bugs Steven Rostedt
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=179285915196.466249.7067056297377577459.stgit@devnote2 \
--to=mhiramat@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=linux-trace-kernel@vger.kernel.org \
--cc=mathieu.desnoyers@efficios.com \
--cc=rostedt@goodmis.org \
--cc=shuah@kernel.org \
/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.