CVE-2026-98641

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 build prologue() takes the exception cb path and never calls push callee regs(). That is the only place find used callee regs() runs, and with it the only place ctx->fp used is set, so the callback prologue does not emit the

mov x25, sp

that points BPF REG FP at the frame the callback runs on. x25 keeps whatever it held when bpf throw() 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 BPF REG FP 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) bpf test run+0x188/0x3e0 bpf prog test run skb+0x47c/0x998 sys bpf+0xbdc/0xdd8 Kernel panic - not syncing: Oops: Fatal exception in interrupt

Set ctx->fp used 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.