---
id: "CVE-2026-99141"
kind: "vulnerability"
aliases: ["CVE-2026-99141"]
title: "Linux kernel: tracing switch can crash the kernel via NULL pointer"
severity: "unknown"
cvss: null
epss: null
exploited: false
status: "open"
category: "runtime"
products: []
ecosystems: []
tags: ["ftrace", "linux-kernel", "runtime", "self-hosted"]
not_affected_if: ["no-ftrace-use", "tracefs-not-exposed"]
published_at: "2026-10-28T11:17:34+00:00"
first_seen_at: "2026-10-28T11:32:35+00:00"
updated_at: "2026-10-28T11:36:06+00:00"
sources: [{"source": "nvd", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-99141", "first_seen_at": "2026-10-28T11:32:35+00:00"}]
---

# Linux kernel: tracing switch can crash the kernel via NULL pointer

When switching ftrace tracers, a leftover function_graph trace buffer can be printed with a NULL flags pointer, causing a kernel NULL pointer dereference. The sources describe a crash (denial of service) from reading the trace file, not code execution.

_Summary, check and fix written by a model from the sources; labelled as such._

## How to check

- `uname -r` and compare against the kernel version that carries the fix, which the sources do not name
- `cat /sys/kernel/tracing/current_tracer` to see whether ftrace is in use at all
- unknown whether the sources list affected version ranges

## Fix

- Update to a Linux kernel build that includes the upstream commit titled 'tracing: Fix crash in print_graph_function_event()'; the fixed version number is unknown from the sources
- unknown whether distributions have shipped the backport

## Timeline

- 2026-10-28T11:32:35+00:00 nvd https://nvd.nist.gov/vuln/detail/CVE-2026-99141

## From the sources

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.

---

_Free to read at a human pace. An API with keys and an MCP server are in preparation; early access: hello@infrastack.ai_