Hello, is there anything I can do at this point to address this issue ?

/Fredrik

On Tue, May 19, 2026 at 10:25:04AM +0200, Fredrik Markstrom wrote:

On Mon, May 18, 2026 at 04:06:11PM +0100, Will Deacon wrote:

quoted

On Thu, Apr 30, 2026 at 12:55:12PM +0200, Fredrik Markstrom wrote:

quoted

Perf callchain unwinding follows userspace frame pointers via
copy_from_user. A corrupted or malicious frame pointer can point
into device I/O memory mapped into the process (e.g. via UIO or
/dev/mem), causing the kernel to read from MMIO regions in PMU
interrupt context. Such reads can have side effects on hardware
(clearing status registers, advancing FIFOs, triggering DMA) and
on arm64 can produce a synchronous external abort that panics the
kernel.

Hmm, but why is unwinding special in this case? If userspace has access
to sensitive MMIO/device mappings, it can presumably pass them to
syscalls and trigger crashes all over the place?

You’re totally right, a broken app with access to hardware like this can
already cause chaos by passing bad pointers to syscalls etc. But the big
difference here is who is to blame when things crash.
 
If an app passes a bad pointer to a syscall, it’s self-inflicted.

Unwinding here is asynchronous and unrelated to the application.
Perf interrupts a perfectly healthy app at a random moment. If that app
is using the frame pointer as a normal register (totally legal in
optimized code), it might hold a junk value that points to MMIO memory.
 
If the kernel blindly follows that junk pointer during an unwind, perf
causes the crash. I think it's acceptable that an app (with hardware
access) causes a crash if buggy, but I don't think it's acceptable that
a profiling tool is causing a crash just by looking at it.

Fredrik

quoted

Will