Re: [PATCH] tracing: Fix use-after-free on field name/type of dynamic probe events

From: Steven Rostedt

Date: Mon Aug 24 2026 - 14:45:23 EST


On Mon, 24 Aug 2026 15:10:11 +0800
Henry Martin <bsdhenrymartin@xxxxxxxxx> wrote:

> Fields of a probe-based dynamic event (kprobe, uprobe and eprobe
> events) are created from the argument name and type strings of the
> trace_probe that first registers the event, as plain pointer
> references without copying.
>
> When several probes are appended to the same event, they share the
> trace_event_call and its field list, which stays the one defined by
> the primary probe. Deleting just the primary probe with

What do you mean by "appended to the same event"? Do you mean eprobes?

Can you post a reproducer for this?

> "-:group/event symbol" frees the trace_probe and its argument
> strings, while the event call is kept registered by the remaining
> sibling probes. field->name and field->type are left dangling, and
> any field lookup - e.g. writing to events/<grp>/<ev>/filter - reads
> freed memory:
>
> BUG: KASAN: slab-use-after-free in strcmp+0xa7/0xb0
> Call trace:
> trace_find_event_field+0xd6/0x220
> parse_pred
> process_preds
> create_filter
> apply_event_filter
> event_filter_write
>
> Make the field own its strings: duplicate name and type with
> kstrdup_const() in __trace_define_field() and release them with
> kfree_const() in trace_destroy_fields(). Fields of static trace
> events still reference their kernel/module rodata string literals
> directly, as kstrdup_const()/kfree_const() only touch memory that
> was actually allocated.

Wrong fix.

>
> The issue was found by the autokbug dynamic kernel fuzzer at Tencent
> Yunding Lab.
>
> Fixes: ca89bc071d5e4 ("tracing/kprobe: Add multi-probe per event support")
> Signed-off-by: Henry Martin <bsdhenrymartin@xxxxxxxxx>
> ---
> kernel/trace/trace_events.c | 14 ++++++++++++--
> 1 file changed, 12 insertions(+), 2 deletions(-)
>
> diff --git a/kernel/trace/trace_events.c b/kernel/trace/trace_events.c
> index c01b10b99f67e..ee3b93fa09ee8 100644
> --- a/kernel/trace/trace_events.c
> +++ b/kernel/trace/trace_events.c

This is a bug with trace_probes.c and not trace_events.c. This should be
fixed without touching trace_events.c. That is, the trace_probes.c code (or
trace_eprobes.c if it's only affects eprobes) should handle this issue.

If you had an example, I could have figured out exactly where to place the
fix.

-- Steve

> @@ -123,8 +123,18 @@ static int __trace_define_field(struct list_head *head, const char *type,
> if (!field)
> return -ENOMEM;
>
> - field->name = name;
> - field->type = type;
> + field->name = kstrdup_const(name, GFP_TRACE);
> + if (!field->name) {
> + kmem_cache_free(field_cachep, field);
> + return -ENOMEM;
> + }
> +
> + field->type = kstrdup_const(type, GFP_TRACE);
> + if (!field->type) {
> + kfree_const(field->name);
> + kmem_cache_free(field_cachep, field);
> + return -ENOMEM;
> + }
>
> if (filter_type == FILTER_OTHER)
> field->filter_type = filter_assign_type(type);
> @@ -225,6 +235,8 @@ static void trace_destroy_fields(struct trace_event_call *call)
> head = trace_get_fields(call);
> list_for_each_entry_safe(field, next, head, link) {
> list_del(&field->link);
> + kfree_const(field->name);
> + kfree_const(field->type);
> kmem_cache_free(field_cachep, field);
> }
> }