perf trace: Fix segmentation fault when access syscall info on arm64
'perf trace' reports the segmentation fault as below on Arm64: # perf trace -e string -e augmented_raw_syscalls.c LLVM: dumping tools/perf/examples/bpf/augmented_raw_syscalls.o perf: Segmentation fault Obtained 12 stack frames. perf(sighandler_dump_stack+0x47) [0xaaaaac96ac87] linux-vdso.so.1(+0x5b7) [0xffffadbeb5b7] /lib/aarch64-linux-gnu/libc.so.6(strlen+0x10) [0xfffface7d5d0] /lib/aarch64-linux-gnu/libc.so.6(_IO_vfprintf+0x1ac7) [0xfffface49f97] /lib/aarch64-linux-gnu/libc.so.6(__vsnprintf_chk+0xc7) [0xffffacedfbe7] perf(scnprintf+0x97) [0xaaaaac9ca3ff] perf(+0x997bb) [0xaaaaac8e37bb] perf(cmd_trace+0x28e7) [0xaaaaac8ec09f] perf(+0xd4a13) [0xaaaaac91ea13] perf(main+0x62f) [0xaaaaac8a147f] /lib/aarch64-linux-gnu/libc.so.6(__libc_start_main+0xe3) [0xfffface22d23] perf(+0x57723) [0xaaaaac8a1723] Segmentation fault This issue is introduced by commit 30a910d7 ("perf trace: Preallocate the syscall table"), it allocates trace->syscalls.table[] array and the element count is 'trace->sctbl->syscalls.nr_entries'; but on Arm64, the system call number is not continuously used; e.g. the syscall maximum id is 436 but the real entries is only 281. So the table is allocated with 'nr_entries' as the element count, but it accesses the table with the syscall id, which might be out of the bound of the array and cause the segmentation fault. This patch allocates trace->syscalls.table[] with the element count is 'trace->sctbl->syscalls.max_id + 1', this allows any id to access the table without out of the bound. Signed-off-by: Leo Yan <leo.yan@linaro.org> Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com> Cc: Daniel Borkmann <daniel@iogearbox.net> Cc: Jiri Olsa <jolsa@redhat.com> Cc: Martin KaFai Lau <kafai@fb.com> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Song Liu <songliubraving@fb.com> Cc: Yonghong Song <yhs@fb.com> Fixes: 30a910d7 ("perf trace: Preallocate the syscall table") Link: http://lkml.kernel.org/r/20190809104752.27338-1-leo.yan@linaro.org Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Please register or sign in to comment