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

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 traceprobedefineargfields() by handing the probearg name/type strings to tracedefinefield(), which only stores the pointers without copying. Those strings are owned by the traceprobe 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 vfsread a1=$arg1' > kprobeevents # append B: shares A's event call echo 'p:kprobes/ev vfswrite a1=$arg1' >> kprobeevents # delete only A (matched by symbol), B survives echo '-:kprobes/ev vfsread' >> kprobeevents

frees A's args (traceprobecleanup() -> traceprobefreeprobearg()), but traceprobeunlink() keeps the traceprobeevent 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 tracefindeventfield parsepred processpreds createfilter applyeventfilter eventfilterwrite

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 traceprobedefineargfields() duplicate the name and type strings and anchor the copies on the traceprobeevent, which embeds the event call and outlives every individual probe; traceprobeeventfree() releases them.

The reproducer above triggers reliably; the field lookup and the delete both run under eventmutex, 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.