CVE-2025-38493: tracing/osnoise: Fix crash in timerlat_dump_stack()

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

tracing/osnoise: Fix crash in timerlatdumpstack()

We have observed kernel panics when using timerlat with stack saving, with the following dmesg output:

memcpy: detected buffer overflow: 88 byte write of buffer size 0 WARNING: CPU: 2 PID: 8153 at lib/stringhelpers.c:1032 fortifyreport+0x55/0xa0 CPU: 2 UID: 0 PID: 8153 Comm: timerlatu/2 Kdump: loaded Not tainted 6.15.3-200.fc42.x8664 #1 PREEMPT(lazy) Call Trace: <TASK> ? tracebufferlockreserve+0x2a/0x60 fortifypanic+0xd/0xf timerlatdumpstack.cold+0xd/0xd timerlatdumpstack.part.0+0x47/0x80 timerlatfdread+0x36d/0x390 vfsread+0xe2/0x390 ? syscallexittousermode+0x1d5/0x210 ksysread+0x73/0xe0 dosyscall64+0x7b/0x160 ? excpagefault+0x7e/0x1a0 entrySYSCALL64afterhwframe+0x76/0x7e

timerlatdumpstack() constructs the ftrace stack entry like this:

struct stackentry entry; ... memcpy(&entry->caller, fstack->calls, size); entry->size = fstack->nrentries;

Since commit e7186af7fb26 ("tracing: Add back FORTIFYSOURCE logic to kernelstack event structure"), struct stackentry marks its caller field with countedby(size). At the time of the memcpy, entry->size contains garbage from the ringbuffer, which under some circumstances is zero, triggering a kernel panic by buffer overflow.

Populate the size field before the memcpy so that the out-of-bounds check knows the correct size. This is analogous to ftracetracestack().