CVE-2026-99141: tracing: Fix crash in print_graph_function_event()

In the Linux kernel, the following vulnerability has been resolved:

tracing: Fix crash in printgraphfunctionevent()

tracingsettracer() assigns the flags of the newly selected tracer with:

tr->currenttraceflags = t->flags ? : t->tracer->flags;

If the new tracer defines neither static flags nor default flags, like hwlat, irqsoff or wakeup, addtracer() has no per instance flags copy for it, and both operands are NULL, so tr->currenttraceflags ends up being NULL as well.

The ring buffer is not cleared when switching tracers: it is reset inside tracerinit(), after currenttraceflags was already assigned. If the buffer still holds functiongraph 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:printgraphfunctionevent+0xe/0x20 Call Trace: sshow+0x4d/0x110 seqreaditer+0x2d4/0x490 seqread+0x130/0x170 vfsread+0xb5/0x370 ksysread+0x6d/0xe0 dosyscall64+0xbc/0x450

The snapshot buffer is not reset at all, so this can be reproduced without a race:

echo functiongraph > /sys/kernel/tracing/currenttracer echo 1 > /sys/kernel/tracing/snapshot echo hwlat > /sys/kernel/tracing/currenttracer cat /sys/kernel/tracing/snapshot

Rather than teaching every user of tr->currenttraceflags about this corner case, make sure it is never NULL: when the newly selected tracer has no flags at all, tracingsettracer() falls back to a static empty notracerflags. runtracerselftest() 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.