Crash during local unwinding with aarch64 pointer authentication

The bug is in src/aarch64/Gtrace.c: around line 486, the saved link register is read via ACCESS_MEM_FAST into pc without stripping the pointer-authentication bits, while the DWARF path already calls aarch64_strip_pac_local. Start by reading _ULaarch64_tdep_trace and that helper, then reproduce on a PAC-enabled aarch64 machine. Done means the traced PC matches the DWARF-computed IP with no PAC bits set, and the trace no longer crashes.

Hello,

I'm trying to add libunwind to do local crash-reporting on an application using pointer authentication on aarch64. The support for that looks like it should have been added in https://github.com/libunwind/libunwind/pull/360, but it doesn't seem complete.

When running with UNW_DEBUG_LEVEL=99, this is the last log output before the segfault:

I attached a debugger and found some interesting events leading up to the crash:

at Gtrace.c:465 (permalink):

(gdb) print (void*)pc
$2 = (void *) 0xaaaaaad92637 <rb_vm_bugreport+2055>
(gdb) print (void*)((struct cursor *)c)->dwarf.ip
$4 = (void *) 0xaaaaaab774ac <rb_bug_without_die+136>

So looks like pc is the program counter in this frame, and c->dwarf.ip is the program counter in the previous frame as computed from the DWARF info. The pointer authentication seems to be correctly stripped from the computed previous IP by the call to aarch64_strip_pac_local from #360. So far, so good.

(we can verify for sure that this call has pointer authentication, because gdb says so - it says [PAC] for frame 4)

BUT, then the subsequent code seems to re-compute the PC-in-previous-frame by looking at the saved value of LR on the stack here - https://github.com/libunwind/libunwind/blob/87a98de7fa5669ef1ea103984d8d26d0cf859df5/src/aarch64/Gtrace.c#L486. The value retrieved from the stack seems to be the version of the return address with pointer authentication:

(gdb) info line
Line 486 of "aarch64/Gtrace.c" starts at address 0xfffff7f676ac <_ULaarch64_tdep_trace+812>
   and ends at 0xfffff7f676bc <_ULaarch64_tdep_trace+828>.
(gdb) list
481
482	    case UNW_AARCH64_FRAME_STANDARD:
483	      /* Advance standard traceable frame. */
484	      cfa = (f->cfa_reg_sp ? sp : fp) + f->cfa_reg_offset;
485	      if (likely(f->lr_cfa_offset != -1))
486	        ACCESS_MEM_FAST(ret, c->validate, d, cfa + f->lr_cfa_offset, pc);
487	      else if (lr != 0)
488	      {
489	        /* Use the saved link register as the new pc. */
490	        pc = lr;
(gdb) print (void*)pc
$5 = (void *) 0xaaaaaad92637 <rb_vm_bugreport+2055>
(gdb) next
(gdb) print (void*)pc
$7 = (void *) 0x72aaaaaab774ac
(gdb) print (void*)((struct cursor *)c)->dwarf.ip
$8 = (void *) 0xaaaaaab774ac <rb_bug_without_die+136>

The value saved into the pc variable here is 0x72aaaaaab774ac, which looks a lot like the actual return address (0xaaaaaab774ac) except with bonus pointer authentication bits.

Attempting to continue execution from here then leads to a segfault, because:

• This incorrect-pc-with-pac gets passed into the next iteration of unw_step and trace_init_addr,
• And then it gets set onto loc[UNW_AARCH64_PC] here: https://github.com/libunwind/libunwind/blob/87a98de7fa5669ef1ea103984d8d26d0cf859df5/src/aarch64/Gtrace.c#L250
• and that subsequently leads to a segfault with this stack, which attempts to dereference this address

(gdb) bt
#0  0x0000fffff7f649ac in access_mem (as=<optimized out>, addr=32275797330326700, val=0xffffffffdb48,
    write=<optimized out>, arg=<optimized out>) at aarch64/Ginit.c:362
#1  0x0000fffff7f66af0 in is_plt_entry (c=0xffffffffe078) at aarch64/Gstep.c:44
#2  _ULaarch64_step (cursor=cursor@entry=0xffffffffe078) at aarch64/Gstep.c:228
#3  0x0000fffff7f6799c in trace_init_addr (sp=281474976706976, fp=281474976706976, pc=32275797330326699,
    cfa=281474976706976, cursor=0xffffffffe078, f=<optimized out>) at ../include/tdep-aarch64/libunwind_i.h:161
#4  trace_lookup (sp=281474976706976, fp=281474976706976, pc=32275797330326699, cfa=281474976706976,
    cache=0xfffff7fe9fe0, cursor=0xffffffffe078) at aarch64/Gtrace.c:333
#5  _ULaarch64_tdep_trace (cursor=cursor@entry=0xffffffffe078, buffer=buffer@entry=0xaaaaaafdfa50 <trace>,
    size=size@entry=0xffffffffdc84) at aarch64/Gtrace.c:451
#6  0x0000fffff7f637d8 in unw_backtrace (buffer=buffer@entry=0xaaaaaafdfa50 <trace>, size=size@entry=1024)
    at mi/backtrace.c:70
#7  0x0000aaaaaad92638 in rb_print_backtrace () at vm_dump.c:785
#8  rb_vm_bugreport (ctx=ctx@entry=0x0) at vm_dump.c:1093
#9  0x0000aaaaaab774ac [PAC] in rb_bug_without_die (fmt=fmt@entry=0xaaaaaae97390 "%s", args=...) at error.c:790
#10 0x0000aaaaaaadd8b8 [PAC] in rb_bug (fmt=fmt@entry=0xaaaaaae97390 "%s") at error.c:798
#11 0x0000aaaaaab77544 [PAC] in kernel_rb_bug (self=<optimized out>, str=<optimized out>) at error.c:3029
#12 0x0000aaaaaad6936c [PAC] in vm_call_cfunc_with_frame_ (stack_bottom=<optimized out>, argv=<optimized out>,
    argc=<optimized out>, calling=<optimized out>, reg_cfp=<optimized out>, ec=<optimized out>)
    at /home/ktsanaktsidis.linux/ruby/vm_insnhelper.c:3285
#13 vm_call_cfunc_with_frame (calling=<optimized out>, reg_cfp=<optimized out>, ec=<optimized out>)
    at /home/ktsanaktsidis.linux/ruby/vm_insnhelper.c:3306
#14 vm_call_cfunc (ec=0xaaaaaafe9610, reg_cfp=0xfffff77feed0, calling=<optimized out>)
    at /home/ktsanaktsidis.linux/ruby/vm_insnhelper.c:3408
#15 0x0000aaaaaad83070 [PAC] in vm_sendish (method_explorer=<optimized out>, block_handler=<optimized out>,
    cd=<optimized out>, reg_cfp=<optimized out>, ec=<optimized out>)
    at /home/ktsanaktsidis.linux/ruby/vm_callinfo.h:367
#16 vm_exec_core (ec=0xaaaaaafe9610, initial=32275797330326700, initial@entry=0)
    at /home/ktsanaktsidis.linux/ruby/insns.def:820
#17 0x0000aaaaaad76288 [PAC] in rb_vm_exec (ec=0xaaaaaafe9610, jit_enable_p=jit_enable_p@entry=true) at vm.c:2410
#18 0x0000aaaaaad8bb9c [PAC] in rb_iseq_eval_main (iseq=iseq@entry=0xfffff7b721c0) at vm.c:2669
#19 0x0000aaaaaab7cc94 in rb_ec_exec_node (ec=ec@entry=0xaaaaaafe9610, n=n@entry=0xfffff7b721c0) at eval.c:289
#20 0x0000aaaaaab8215c [PAC] in ruby_run_node (n=0xfffff7b721c0) at eval.c:330
#21 0x0000aaaaaaae46bc [PAC] in rb_main (argv=0xfffffffff9c8, argc=2) at ./main.c:39
#22 main (argc=<optimized out>, argv=<optimized out>) at ./main.c:58
(gdb) print (void*)32275797330326700
$9 = (void *) 0x72aaaaaab774ac

I don't really understand libunwind well enough to know what the fix is though. It seems to me that tdep_trace should just read the previous frame PC from the dwarf result directly, rather than looking at the LR? I suppose this unifies the frame-pointer-chasing and dwarf unwinding code paths though doesn't it. At the very least this calculation of PC-from-saved-LR needs to also strip the pointer auth bits.

Any thoughts? Thanks for reading this long rant!