Re: [PATCH v5 8/8] rtla/osnoise: Trace IPI events when recording a trace file
From: sashiko-bot@kernel.org
Date: 2026-09-02 13:55:19
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider: - [Medium] Out-of-bounds read in osnoise_ipi_cpumask_handler due to using CPU_AND on a dynamically sized trace event field. -- commit 25aed6d1003b38e3162e406562eb91e3fee93066 Author: Valentin Schneider [off-list ref] rtla/osnoise: Trace IPI events when recording a trace file IPIs can now be monitored and accounted by osnoise top. When that is the case, also record them when saving a trace file. To match what is being recorded by the tool for its own analysis, event filters are applied to the events recorded to the trace output.
quoted hunk ↗ jump to hunk
diff --git a/tools/tracing/rtla/src/osnoise_top.c b/tools/tracing/rtla/src/osnoise_top.c index afab2f341a1e9..87d28865515b5 100644 --- a/tools/tracing/rtla/src/osnoise_top.c +++ b/tools/tracing/rtla/src/osnoise_top.c@@ -392,7 +392,7 @@ osnoise_ipi_cpumask_handler(struct trace_seq *s, struct tep_record *record, */ struct osnoise_tool *osnoise_init_top(struct common_params *params) { - bool ipi_filters_enabled = false; + bool ipi_filters_enabled; struct osnoise_tool *tool; int retval;
[Severity: Medium]
Can this lead to an out-of-bounds read when processing the IPI cpumask?
Looking at osnoise_ipi_cpumask_handler() above, it processes the
ipi_send_cpumask trace event:
tools/tracing/rtla/src/osnoise_top.c:osnoise_ipi_cpumask_handler() {
...
cpumask = tep_get_field_raw(s, event, "cpumask", record, &len, 1);
...
event_cpus = (cpu_set_t *)cpumask;
...
CPU_AND(&cpumask_tmp_cpus, event_cpus, ¶ms->common.monitored_cpus);
...
}
tep_get_field_raw() returns a pointer to a dynamically sized field and its
actual length in len.
Since the code ignores len and casts the pointer to a cpu_set_t *, and
glibc's CPU_AND() unconditionally iterates and reads sizeof(cpu_set_t)
(128 bytes) from the source pointers, does this read well past the end
of the trace field for the cpumask (which would be 8 bytes for 64 CPUs)?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260902123942.695822-1-vschneid@redhat.com?part=8