CVE-2026-89746: tracing: Fix use-after-free with same-name named triggers

[Greg Kroah-Hartman <gregkh@linuxfoundation.org>]

From: Greg Kroah-Hartman <gregkh@kernel.org>

Description
===========

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 named_data.  Both are added to
tr->hist_vars by save_hist_vars() during event_hist_trigger_parse(),
because save_hist_vars() is called before event_trigger_register() while
the named reuse is only detected later, in hist_register_trigger().

In the named-data branch hist_register_trigger() then frees the second
histogram's hist_data via destroy_hist_data(), but never removes its
tr->hist_vars list entry, leaving a dangling pointer and leaking the
trace_array reference it holds.

A later hist trigger that references a variable makes find_var_file()
walk tr->hist_vars and dereference the freed hist_data.  The bug is
reproducible from userspace by writing three hist triggers to tracefs:

  cd /sys/kernel/tracing
  echo 'hist:keys=common_pid:x=common_pid:name=mh' > events/sched/sched_switch/trigger
  echo 'hist:keys=common_pid:x=common_pid:name=mh' > events/sched/sched_process_fork/trigger
  echo 'hist:keys=common_pid:vals=$x' > events/sched/sched_process_exit/trigger

The third write panics the kernel:

  BUG: KASAN: slab-use-after-free in find_var_file.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:
    find_var_file.part.0
    find_event_var
    parse_atom
    parse_expr
    __create_val_field
    event_hist_trigger_parse
    trigger_process_regex
    event_trigger_write
    vfs_write
    ksys_write
    do_syscall_64
    entry_SYSCALL_64_after_hwframe
  Allocated by task 1:
    event_hist_trigger_parse
  Freed by task 1:
    hist_register_trigger+0x618/0xa30
    event_hist_trigger_parse
  The buggy address belongs to freed 2048-byte region
  Oops: general protection fault ... RIP: find_var_file.part.0
  Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b

Fix by removing the hist_data from tr->hist_vars and releasing the
trace_array reference in the named-data branch of hist_register_trigger()
before freeing the hist_data.

The Linux kernel CVE team has assigned CVE-2026-89746 to this issue.


Affected and fixed versions
===========================

	Issue introduced in 6.12.18 with commit 435d2964af815aae456db554c62963b4515f19d0 and fixed in 6.12.109 with commit 477d762be4b0ffaf01429ccd88859e93b0ec28cc
	Issue introduced in 6.14 with commit 6f86bdeab633a56d5c6dccf1a2c5989b6a5e323e and fixed in 6.18.50 with commit b1a49c22de01faf176d44e5caa765e237353a579
	Issue introduced in 6.14 with commit 6f86bdeab633a56d5c6dccf1a2c5989b6a5e323e and fixed in 7.2.4 with commit 83d1ae0406d8eade219a81b401e201702dd9dc55
	Issue introduced in 6.14 with commit 6f86bdeab633a56d5c6dccf1a2c5989b6a5e323e and fixed in 7.3-rc1 with commit a7318172aa332a161fb9618286e64454c827f8fd
	Issue introduced in 6.1.130 with commit 5ae1b18f05ee2b849dc03b6c15d7da0c1c6efa77
	Issue introduced in 6.6.81 with commit 43b254d46c740bf9dbe65709afa021dd726dfa99
	Issue introduced in 6.13.6 with commit f1ae50cfb818ce1ac7a674406dfadb7653e2552d

Please see https://www.kernel.org for a full list of currently supported
kernel versions by the kernel community.

Unaffected versions might change over time as fixes are backported to
older supported kernel versions.  The official CVE entry at
	https://cve.org/CVERecord/?id=CVE-2026-89746
will be updated if fixes are backported, please check that for the most
up to date information about this issue.


Affected files
==============

The file(s) affected by this issue are:
	kernel/trace/trace_events_hist.c


Mitigation
==========

The Linux kernel CVE team recommends that you update to the latest
stable kernel version for this, and many other bugfixes.  Individual
changes are never tested alone, but rather are part of a larger kernel
release.  Cherry-picking individual commits is not recommended or
supported by the Linux kernel community at all.  If however, updating to
the latest release is impossible, the individual changes to resolve this
issue can be found at these commits:
	https://git.kernel.org/stable/c/477d762be4b0ffaf01429ccd88859e93b0ec28cc
	https://git.kernel.org/stable/c/b1a49c22de01faf176d44e5caa765e237353a579
	https://git.kernel.org/stable/c/83d1ae0406d8eade219a81b401e201702dd9dc55
	https://git.kernel.org/stable/c/a7318172aa332a161fb9618286e64454c827f8fd