Cloudanix VulnDB

CVE-2026-99141

None

CVSS

—

EPSS

0.2%

Published

Oct 28, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A bug in the Linux kernel's tracing code can cause the whole system to crash when certain performance tracing tools are switched on and off.

Exploitation
Local Privilege
Attacker needs
Local User
Complexity
Low
Impact
Denial Of Service
Component
OS kernel
Class
Memory Corruption
Remediation
Patch
Effort
Medium
Patch risk
Low

What it actually does

NULL pointer dereference in print_graph_function_event() when current_trace_flags is left uninitialized after switching to tracers (hwlat, irqsoff, wakeup) that define neither static nor default flags; the ring buffer is not cleared, so stale function_graph entries trigger the crash on read.

Why it matters to the business

Kernel panic or denial of service on systems using ftrace, especially during tracer switching or snapshot reads, leading to unplanned reboots and service disruption; low exploitability reduces immediate risk but still requires prompt patching on affected kernels.

How an attack unfolds

An attacker with local access writes a sequence of tracer switches and snapshot operations to leave stale function_graph data in the ring buffer, then triggers a read (cat trace or snapshot) that dereferences the NULL current_trace_flags pointer, causing a kernel crash.

How to fix it

Apply the kernel patch that ensures tracing_set_tracer() and run_tracer_selftest() fall back to a static empty no_tracer_flags when the selected tracer supplies no flags; rebuild and reboot to the fixed kernel.

How to confirm the fix worked

Confirm the patch is present by inspecting tracing.c for the no_tracer_flags fallback; reproduce the original reproducer steps and verify no NULL dereference occurs.

Typical attack path

  1. echo function_graph > /sys/kernel/tracing/current_tracer
  2. echo 1 > /sys/kernel/tracing/snapshot
  3. echo hwlat > /sys/kernel/tracing/current_tracer
  4. cat /sys/kernel/tracing/snapshot

How to detect it

Search kernel logs for NULL pointer dereference oops with RIP in print_graph_function_event and call trace showing s_show or seq_read; correlate with ftrace sysfs writes immediately preceding the crash.

  • BUG: kernel NULL pointer dereference, address: 0000000000000000
  • RIP: print_graph_function_event
  • echo function_graph > /sys/kernel/tracing/current_tracer
  • echo hwlat > /sys/kernel/tracing/current_tracer
  • cat /sys/kernel/tracing/snapshot

What your security team should do

  • Prioritize kernel updates on all systems exposing ftrace interfaces within the next maintenance window
  • Restrict unprivileged access to /sys/kernel/tracing/current_tracer and snapshot files via mount options or LSM policy
  • Monitor for kernel oops containing print_graph_function_event until patches are deployed

The record

In the Linux kernel, the following vulnerability has been resolved: tracing: Fix crash in print_graph_function_event() tracing_set_tracer() assigns the flags of the newly selected tracer with: tr->current_trace_flags = t->flags ? : t->tracer->flags; If the new tracer defines neither static flags nor default flags, like hwlat, irqsoff or wakeup, add_tracer() has no per instance flags copy for it, and both operands are NULL, so tr->current_trace_flags ends up being NULL as well. The ring buffer is not cleared when switching tracers: it is reset inside tracer_init(), after current_trace_flags was already assigned. If the buffer still holds function_graph entries of the previous tracer, printing one of them dereferences the NULL pointer. This was hit by cat trace during an ftrace stress test: BUG: kernel NULL pointer dereference, address: 0000000000000000 #PF: supervisor read access in kernel mode RIP: 0010:print_graph_function_event+0xe/0x20 Call Trace: s_show+0x4d/0x110 seq_read_iter+0x2d4/0x490 seq_read+0x130/0x170 vfs_read+0xb5/0x370 ksys_read+0x6d/0xe0 do_syscall_64+0xbc/0x450 The snapshot buffer is not reset at all, so this can be reproduced without a race: echo function_graph > /sys/kernel/tracing/current_tracer echo 1 > /sys/kernel/tracing/snapshot echo hwlat > /sys/kernel/tracing/current_tracer cat /sys/kernel/tracing/snapshot Rather than teaching every user of tr->current_trace_flags about this corner case, make sure it is never NULL: when the newly selected tracer has no flags at all, tracing_set_tracer() falls back to a static empty no_tracer_flags. run_tracer_selftest() can hit the same case, so the same fallback is added there too. The existing users already handle opts == NULL, so these tracers keep behaving as before.

Affected packages

Ecosystem Package Introduced Fixed