CVE-2026-98076

In the Linux kernel, the following vulnerability has been resolved:

tracing/probes: Fix use-after-free on field name/type of events with multiple probes

The fields of a probe-based dynamic event (kprobe, uprobe, eprobe and

fprobe events) are created in traceprobe_define_arg_fields() by handing

the probe_arg name/type strings to trace_define_field(), which only

stores the pointers without copying. Those strings are owned by the

trace_probe and are freed when that probe is removed.

An event can have several probes attached. The field list is defined

only once, by the first probe that registers the event, but it is kept

alive by any surviving sibling probe. Deleting just that first probe by

symbol -

# primary A: fields are defined from A's args

echo 'p:kprobes/ev vfs_read a1=$arg1' > kprobe_events

# append B: shares A's event call

echo 'p:kprobes/ev vfs_write a1=$arg1' >> kprobe_events

# delete only A (matched by symbol), B survives

echo '-:kprobes/ev vfs_read' >> kprobe_events

frees A's args (trace_probe_cleanup() -> traceprobe_free_probe_arg()),

but trace_probe_unlink() keeps the trace_probe_event because the probe

list is not empty. The event call stays registered via B while its

fields now reference freed memory. Any field lookup then reads it, e.g.

echo 'a1 == 1' > events/kprobes/ev/filter

BUG: KASAN: slab-use-after-free in strcmp+0xa7/0xb0

Call Trace:

strcmp

trace_find_event_field

parse_pred

process_preds

create_filter

apply_event_filter

event_filter_write

field->name references parg->name (kstrdup'd, freed with the probe) and,

for array arguments, field->type references parg->fmt (kmalloc'd, freed

with the probe) - the scalar type otherwise points at the static

fmttype rodata, which is safe.

Have traceprobe_define_arg_fields() duplicate the name and type strings

and anchor the copies on the trace_probe_event, which embeds the event

call and outlives every individual probe; trace_probe_event_free()

releases them.

The reproducer above triggers reliably; the field lookup and the delete

both run under event_mutex, so this is a dangling reference after

removal rather than a race.

The issue was found by the autokbug dynamic kernel fuzzer at Tencent

Yunding Lab.