Re: [PATCH v5 8/8] rtla/osnoise: Trace IPI events when recording a trace file

[sashiko-bot@kernel.org]

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 <vschneid@redhat.com>

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.

> 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, &params->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