Live › vulnerability › CVE-2026-99141
Go to dashboardWhen 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 written from the sources below. Check the originals before acting.
First seen by InfraStack 2026-10-28 11:32 UTC. All times on this page are UTC.
Systems running a Linux kernel with ftrace tracing enabled and tracefs mounted, where a user or tool can change tracers and read the trace file. The sources describe a reproduction via the tracing sysfs files, which normally requires root. Machines that do not use ftrace are unlikely to be affected.
No product ranges from the sources yet.
uname -r and compare against the kernel version that carries the fix, which the sources do not namecat /sys/kernel/tracing/current_tracer to see whether ftrace is in use at allEach row is the first time that source carried this signal. The analyst’s rows are its own findings.
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.
This page as .md · .json · in your agent: get_signal("CVE-2026-99141")
NVD data is provided by NIST and is public domain. Posts quoted belong to their authors.