CVE-2026-99141

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.