linux-kernel - Re: [PATCH] tracing/eprobe: Update cond flag before enabling trigger

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20221117211726.4bbbb96a@gandalf.local.home>
Date:   Thu, 17 Nov 2022 21:17:26 -0500
From:   Steven Rostedt <rostedt@...dmis.org>
To:     Rafael Mendonca <rafaelmendsr@...il.com>
Cc:     Masami Hiramatsu <mhiramat@...nel.org>,
        "Tzvetomir Stoyanov (VMware)" <tz.stoyanov@...il.com>,
        linux-kernel@...r.kernel.org, linux-trace-kernel@...r.kernel.org,
        Tom Zanussi <zanussi@...nel.org>
Subject: Re: [PATCH] tracing/eprobe: Update cond flag before enabling
 trigger

On Wed, 16 Nov 2022 16:25:51 -0300
Rafael Mendonca <rafaelmendsr@...il.com> wrote:

> That happens because enable_eprobe() will eventually trigger the
> kmem/mm_page_alloc trace event:
> 
> - enable_eprobe [trace_eprobe.c]
>   - trace_event_trigger_enable_disable [trace_events_trigger.c]
>     - trace_event_enable_disable [trace_events.c]
>       - __ftrace_event_enable_disable [trace_events.c]
>         - trace_buffered_event_enable [trace.c]
>           - alloc_pages_node [gfp.h]
> 	   ...
>             - __alloc_pages [page_alloc.c]
>               - trace_mm_page_alloc // eprobe event file without TRIGGER_COND bit set
> 
> By the time kmem/mm_page_alloc trace event is hit, the eprobe event file
> does not have the TRIGGER_COND flag set yet, which causes the eprobe's
> trigger to be invoked (through the trace_trigger_soft_disabled() path)
> without a trace record, causing a NULL pointer dereference when fetching
> the event fields.
> 
> Fix this by setting the cond flag beforehand when enabling the eprobe's
> trigger.
> 
> Fixes: 7491e2c44278 ("tracing: Add a probe that attaches to trace events")
> Signed-off-by: Rafael Mendonca <rafaelmendsr@...il.com>
> ---

Thanks for the report, but I'm worried that this isn't enough because of
how memory ordering can happen on different architectures. That is, just
because you switch the order of updates, doesn't mean that the architecture
will honor it.

I don't want to add memory barriers in the fast path, but instead we can
simply check if rec is NULL in the handler.

So basically:


static void eprobe_trigger_func(struct event_trigger_data *data,
				struct trace_buffer *buffer, void *rec,
				struct ring_buffer_event *rbe)
{
	struct eprobe_data *edata = data->private_data;

	if (!rec)
		return;

	__eprobe_trace_func(edata, rec);
}

And this should be documented.

-- Steve