linux-kernel - [BUG] perf segfaults when combining --overwrite and intel

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAP4=nvTab7BnT4uu0iCuFJpZ-_MdY-MYU+Q25QnpygEZKmsQ8A@mail.gmail.com>
Date: Mon, 28 Apr 2025 11:07:21 +0200
From: Tomas Glozar <tglozar@...hat.com>
To: Peter Zijlstra <peterz@...radead.org>, Ingo Molnar <mingo@...hat.com>, 
	Arnaldo Carvalho de Melo <acme@...nel.org>, Namhyung Kim <namhyung@...nel.org>
Cc: linux-perf-users@...r.kernel.org, LKML <linux-kernel@...r.kernel.org>, 
	Wander Costa <wcosta@...hat.com>
Subject: [BUG] perf segfaults when combining --overwrite and intel_pt event

Dear maintainers,

I would like to report a bug in perf I ran into when trying to combine
--overwrite and intel_pt on latest perf from 6.15-rc4:

$ perf --version
perf version 6.15.rc4.gb4432656b36e
$ perf record --overwrite -a -e intel_pt/cyc,noretcomp/k
perf: Segmentation fault
Obtained 16 stack frames.
perf() [0x59aab7]
perf() [0x59ab97]
perf() [0x41a9db]
/lib64/libc.so.6(+0x1a050) [0x7f7fc2e27050]
perf() [0x61bb16]
perf() [0x55fee9]
perf() [0x54a790]
perf() [0x469c92]
perf() [0x46a09f]
perf() [0x46a317]
perf() [0x54ac83]
perf() [0x41c61c]
perf() [0x41c92c]
perf() [0x41cc65]
perf() [0x41ff41]
perf() [0x424015]
Segmentation fault (core dumped)

GDB gives the following backtrace:

(gdb) bt
#0  0x000000000061bb16 in auxtrace_mmap__mmap (mm=0x7c9fa0,
mp=0x7fffffff9008, userpg=0x7ffff7cff000, fd=7) at util/auxtrace.c:136
#1  0x000000000055fee9 in mmap__mmap (map=0x7c9f40, mp=0x7fffffff8ff0,
fd=7, cpu=...) at util/mmap.c:312
#2  0x000000000054a790 in perf_evlist__mmap_cb_mmap (_map=0x7c9f40,
_mp=0x7fffffff8ff0, output=7, cpu=...) at util/evlist.c:825
#3  0x0000000000469c92 in mmap_per_evsel (evlist=0x78f190,
ops=0x7fffffff8fd0, idx=0, mp=0x7fffffff8ff0, cpu_idx=0, thread=0,
   _output=0x7fffffff8f10, _output_overwrite=0x7fffffff8f14,
nr_mmaps=0x7fffffff8f0c) at evlist.c:527
#4  0x000000000046a09f in mmap_per_cpu (evlist=0x78f190,
ops=0x7fffffff8fd0, mp=0x7fffffff8ff0) at evlist.c:620
#5  0x000000000046a317 in perf_evlist__mmap_ops (evlist=0x78f190,
ops=0x7fffffff8fd0, mp=0x7fffffff8ff0) at evlist.c:679
#6  0x000000000054ac83 in evlist__mmap_ex (evlist=0x78f190,
pages=4294967295, auxtrace_pages=1024, auxtrace_overwrite=false,
   nr_cblocks=0, affinity=0, flush=1, comp_level=0) at util/evlist.c:977
#7  0x000000000041c61c in record__mmap_evlist (rec=0x764de0 <record>,
evlist=0x78f190) at builtin-record.c:1310
#8  0x000000000041c92c in record__mmap (rec=0x764de0 <record>) at
builtin-record.c:1359
#9  0x000000000041cc65 in record__open (rec=0x764de0 <record>) at
builtin-record.c:1413
#10 0x000000000041ff41 in __cmd_record (rec=0x764de0 <record>, argc=0,
argv=0x7fffffffe0f0) at builtin-record.c:2492
#11 0x0000000000424015 in cmd_record (argc=0, argv=0x7fffffffe0f0) at
builtin-record.c:4285
#12 0x0000000000461133 in run_builtin (p=0x769260 <commands+288>,
argc=5, argv=0x7fffffffe0f0) at perf.c:351
#13 0x00000000004613a2 in handle_internal_command (argc=5,
argv=0x7fffffffe0f0) at perf.c:404
#14 0x00000000004614f1 in run_argv (argcp=0x7fffffffdedc,
argv=0x7fffffffded0) at perf.c:448
#15 0x00000000004617d7 in main (argc=5, argv=0x7fffffffe0f0) at perf.c:556

Further investigation shows the range associated with userpg, to which
the statement at util/auxtrace.c:136 attempts to write to, is mapped
read-only:

(gdb) info proc mappings
...
0x00007ffff7cff000 0x00007ffff7d80000 0x81000            0x0
     r--s  anon_inode:[perf_event]
...

Compare to a run without --overwrite, where the memory is writable and
everything is good:

(gdb) info proc mappings
...
0x00007ffff7cff000 0x00007ffff7d80000 0x81000            0x0
     rw-s  anon_inode:[perf_event]
...

Let me know if you need any more information.

Tomas