[PATCH 0/2] tracing: fix two histogram stacktrace keys that corrupt memory

Both have the same shape: a histogram field ends up flagged as a
stacktrace while the ftrace_event_field behind it does not describe one.
HIST_FIELD_FN_STACK then reads a __data_loc word out of the record and
follows it, and event_hist_trigger() uses the word it lands on as the
length of a memcpy into a 31 entry array. Neither end of that copy is
bounded. One write to tracefs is enough to take the machine down on a
kernel built with no debug options.

They are independent and have different Fixes tags, so they are two
patches rather than one.

Tested on x86_64:

  - both reproducers panic before and are clean after, with and without
    CONFIG_KASAN
  - ftracetest test.d/trigger gives identical results for all 45 items
    before and after (32 pass, 3 fail, 2 unresolved, 8 unsupported; the
    failures are pre-existing and unrelated)
  - the stacktrace modifier recipe from cc5fc8bfc961 still records
    stacktraces

Donggeun Yoo (2):
  tracing: Fix memory corruption from the stacktrace modifier
  tracing: Fix memory corruption from a "STACKTRACE" histogram key

 kernel/trace/trace_events_hist.c | 13 +++++++++++--
 1 file changed, 11 insertions(+), 2 deletions(-)


base-commit: df2908090cda368b01ff43709f51890076c56157
--
2.53.0