Hello, Short version: I can make a kprobe/kretprobe trace event with dynamic ustring fetch args ask perf_trace_buf_alloc() for more than PERF_MAX_TRACE_SIZE. That hits WARN_ONCE(), and with panic_on_warn=1 it becomes a reproducible kernel panic.
The reproducers create a kprobe or kretprobe trace event with several ustring args pointing at a 4095-byte userspace string, open the event through perf_event_open(PERF_TYPE_TRACEPOINT), and trigger it. The dynamic payload size is then passed to perf_trace_buf_alloc(): WARN_ONCE(size > PERF_MAX_TRACE_SIZE, …) I reproduced this through both kprobe and kretprobe events. Tested environment: Linux version 7.0.9, x86_64 QEMU gcc 12.3.0, GNU ld 2.38 Boot args included: panic_on_warn=1 nokaslr console=ttyS0 Kprobe result: perf buffer not large enough, wanted 16420, have 8192 WARNING: kernel/trace/trace_event_perf.c:405 at perf_trace_buf_alloc+0x111/0x160 Kernel panic - not syncing: kernel: panic_on_warn set … Kretprobe result: perf buffer not large enough, wanted 16428, have 8192 WARNING: kernel/trace/trace_event_perf.c:405 at perf_trace_buf_alloc+0x111/0x160 kretprobe_perf_func+0x24b/0x750 Kernel panic - not syncing: kernel: panic_on_warn set … I checked current mainline source and still see PERF_MAX_TRACE_SIZE as 8192 and the WARN_ONCE path in perf_trace_buf_alloc(). I have reproduced the panic on the 7.0.9 QEMU build above; I have not yet runtime-tested current mainline. My expectation is that a user-defined dynamic trace payload that is too large for the perf trace buffer should be rejected, capped, or dropped without reaching WARN_ONCE(). The attached tarball has README files, both C reproducers, and the full QEMU logs. Thanks, Chuyifei
trace_kprobe_kretprobe_perf_ustring_warn_panic.tar.gz
Description: Unix tar archive
