Cloudanix VulnDB

CVE-2026-89746

High · 7.8

CVSS

7.8

EPSS

0.2%

Published

Sep 11, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A bug in the Linux kernel can make the whole computer crash when certain tracing commands are used together.

Exploitation
Local Privilege
Attacker needs
Low Privilege
Complexity
Low
Impact
Full Compromise
Component
OS kernel
Class
Use After Free
Remediation
Patch
Effort
Medium
Patch risk
Low

What it actually does

Use-after-free in Linux kernel tracing: registering duplicate named hist triggers leaves a dangling pointer in tr->hist_vars after destroy_hist_data() frees the hist_data structure; subsequent variable references via find_var_file() dereference the freed memory.

Why it matters to the business

Systems performing kernel tracing or performance analysis can experience unexpected crashes that interrupt workloads and require manual recovery or reboot.

How an attack unfolds

An attacker with local access writes three crafted hist triggers to tracefs; the first two create a named reuse condition, the third triggers variable resolution that walks the stale list entry and dereferences freed memory, resulting in a kernel panic.

How to fix it

Apply the upstream fix that removes the hist_data entry from tr->hist_vars and releases the trace_array reference before calling destroy_hist_data() in the named-data reuse path; reboot into the patched kernel.

How to confirm the fix worked

Confirm the patch is present by inspecting hist_register_trigger() for the added list removal logic before the destroy_hist_data() call; test by replaying the three-trigger sequence and verifying no panic occurs.

Typical attack path

  1. Obtain local shell or write access to tracefs
  2. Write first named hist trigger to one event
  3. Write second named hist trigger to a different event
  4. Write a third trigger that references the shared variable name
  5. Kernel dereferences freed hist_data and panics

How to detect it

Search kernel logs for KASAN or slab-use-after-free messages referencing find_var_file, find_event_var, or hist_register_trigger; inspect tracefs write activity for repeated name= parameters on different events followed by variable references.

  • BUG: KASAN: slab-use-after-free in find_var_file
  • hist:keys=common_pid.*name=
  • /sys/kernel/tracing/events/*/trigger
  • find_var_file.part.0

What your security team should do

  • Prioritize kernel updates on any system exposing tracefs to untrusted local users
  • Restrict tracefs write access via mount options or permissions until patched
  • Monitor for kernel oops or KASAN reports mentioning find_var_file or hist_register_trigger

The record

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.

Affected packages

Ecosystem Package Introduced Fixed