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
