On Mon, May 18, 2026 at 04:06:11PM +0100, Will Deacon wrote: > On Thu, Apr 30, 2026 at 12:55:12PM +0200, Fredrik Markstrom wrote: > > 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 > > Will
