CVE-2026-98641: bpf, arm64: set up the frame pointer for the exception callback

In the Linux kernel, the following vulnerability has been resolved:

bpf, arm64: set up the frame pointer for the exception callback

A program acting as exception boundary saves all callee-saved registers, so buildprologue() takes the exceptioncb path and never calls pushcalleeregs(). That is the only place findusedcalleeregs() runs, and with it the only place ctx->fpused is set, so the callback prologue does not emit the

mov x25, sp

that points BPFREGFP at the frame the callback runs on. x25 keeps whatever it held when bpfthrow() was called. If the throw came from a subprogram that uses its own BPF stack, that is the subprogram's frame pointer, and since the subprogram never returns it never restores x25 either.

Stack accesses through BPFREGFP are rewritten to be stack pointer relative, so those still land in the callback's own frame. Materializing the register does not: a callback that passes the address of a local variable to a helper hands over an address in the dead subprogram's frame. That address is below the callback's stack pointer by then, and the helper's own call chain covers it, so the helper can write over its own return address. 0x1234 below is the value the helper was asked to store:

pc : 0x1234 lr : 0x1234 Call trace: 0x1234 (P) bpftestrun+0x188/0x3e0 bpfprogtestrunskb+0x47c/0x998 sysbpf+0xbdc/0xdd8 Kernel panic - not syncing: Oops: Fatal exception in interrupt

Set ctx->fpused on the exception callback path so that the existing code further down sets x25 from the stack pointer. The epilogue restores it from the main program's save area along with the other callee-saved registers, as it already does. x86 sets the frame pointer for the callback from the argument it is passed, and powerpc computes it from the stack pointer.