CVE-2026-89746: tracing: Fix use-after-free with same-name named triggers
In the Linux kernel, the following vulnerability has been resolved:
tracing: Fix use-after-free with same-name named triggers
When two hist triggers on different events are registered with the same name=, the second one reuses the first as nameddata. Both are added to tr->histvars by savehistvars() during eventhisttriggerparse(), because savehistvars() is called before eventtriggerregister() while the named reuse is only detected later, in histregistertrigger().
In the named-data branch histregistertrigger() then frees the second histogram's histdata via destroyhistdata(), but never removes its tr->histvars list entry, leaving a dangling pointer and leaking the tracearray reference it holds.
A later hist trigger that references a variable makes findvarfile() walk tr->histvars and dereference the freed histdata. The bug is reproducible from userspace by writing three hist triggers to tracefs:
cd /sys/kernel/tracing echo 'hist:keys=commonpid:x=commonpid:name=mh' > events/sched/schedswitch/trigger echo 'hist:keys=commonpid:x=commonpid:name=mh' > events/sched/schedprocessfork/trigger echo 'hist:keys=commonpid:vals=$x' > events/sched/schedprocessexit/trigger
The third write panics the kernel:
BUG: KASAN: slab-use-after-free in findvarfile.part.0+0x272/0x290 Read of size 8 at addr ffff888001f8a0e0 by task sh/1 CPU: 1 UID: 0 PID: 1 Comm: sh Tainted: G D N Call Trace: findvarfile.part.0 findeventvar parseatom parseexpr createvalfield eventhisttriggerparse triggerprocessregex eventtriggerwrite vfswrite ksyswrite dosyscall64 entrySYSCALL64afterhwframe Allocated by task 1: eventhisttriggerparse Freed by task 1: histregistertrigger+0x618/0xa30 eventhisttriggerparse The buggy address belongs to freed 2048-byte region Oops: general protection fault ... RIP: findvarfile.part.0 Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
Fix by removing the histdata from tr->histvars and releasing the tracearray reference in the named-data branch of histregistertrigger() before freeing the histdata.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Compensating control
Avoid registering multiple histogram (hist) triggers on different trace events that reuse the same named-data variable (e.g., the same $__create_val_field / same 'name' such as via hist:keys=common_pid:vals=$x with name=mh) until the fix is applied, to prevent the scenario where hist_data is freed but its pointer remains in tr->hist_vars.
- Operational
In the named-data branch of hist_register_trigger(), fix the use-after-free by removing the hist_data from tr->hist_vars before releasing/destroying it, and ensure destroy_hist_data() also removes the corresponding tr->hist_vars entry (avoid walking tr->hist_vars later to dereference freed hist_data).
Event History
Frequently Asked Questions
Who can trigger this issue?
A user who can write histogram triggers through tracefs can reproduce the issue. The described reproduction writes trigger definitions under /sys/kernel/tracing/events/.
What sequence is required to reach the use-after-free?
Two histogram triggers on different events must be registered with the same name= value. A later histogram trigger that references a variable, such as $x, can then cause the kernel to walk the stale hist_vars entry and dereference freed histogram data.
What can be done if the fix cannot be applied immediately?
Avoid creating same-name histogram triggers on different events, and avoid adding variable-referencing histogram triggers after such duplicate named triggers exist. Removing or preventing the conflicting tracefs trigger configuration avoids the described trigger sequence.