CVE-2026-98641 in Linux
Summary
by MITRE • 10/18/2026
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.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 10/18/2026
The Linux kernel contains a critical vulnerability in the BPF subsystem on ARM64 architectures related to improper handling of the frame pointer during exception-based control flow transitions. This issue specifically affects programs that act as an exception boundary by saving callee-saved registers, which triggers the build_prologue function to take the exception callback path rather than calling push_callee_regs. The core technical flaw lies in the fact that find_used_callee_regs is only invoked within this specific code path, meaning ctx->fp_used remains unset for exception callbacks. Consequently, the generated prologue fails to emit the instruction mov x25, sp, which is responsible for pointing BPF_REG_FP at the correct stack frame associated with the callback execution context.
As a result of this omission, register x25 retains whatever value it held when bpf_throw was originally called. If the exception originated from a subprogram that utilizes its own distinct BPF stack space, x25 will incorrectly reference that subprograms frame pointer rather than the current callbacks frame. Although standard stack accesses through BPF_REG_FP are rewritten to be relative to the stack pointer and thus correctly land in the callback's allocated memory region, materializing this register for other purposes does not receive such rewriting protection. This discrepancy creates a severe security risk where a callback passing the address of a local variable to a helper function inadvertently hands over an invalid memory address located within the dead subprograms frame space.
The operational impact of this vulnerability is significant and potentially catastrophic. Because the passed address points below the callbacks current stack pointer, it falls into a region that may be covered by the helpers own call chain during execution. This allows the helper to overwrite its own return address or other critical control data on the stack, leading to arbitrary code execution possibilities or immediate system instability. The vulnerability manifests as fatal exceptions in interrupt contexts, often resulting in kernel panics with messages indicating an Oops due to invalid memory access at specific program counter and link register values that reflect the corrupted state of the call trace.
This flaw aligns with CWE-120 Buffer Copy without Checking Size of Input Classic buffer overflow vulnerabilities when considering the potential for stack corruption, as well as CWE-478 Missing Default Case in Switch Statement if viewed through the lens of incomplete logic handling in specific execution paths. From an ATT&CK perspective, this vulnerability facilitates lateral movement and privilege escalation by allowing attackers to manipulate kernel memory structures via crafted BPF programs, potentially leading to full system compromise. The issue is particularly dangerous because it involves low-level register manipulation that bypasses standard safety checks inherent in higher-level abstractions.
To mitigate this risk, the Linux kernel developers have implemented a fix that explicitly sets ctx->fp_used on the exception callback path. This ensures that subsequent code correctly initializes x25 from the stack pointer, thereby aligning the frame pointer with the active execution context. The epilogue is also adjusted to restore x25 from the main programs save area along with other callee-saved registers, maintaining consistency across different architectural implementations such as x86 and powerpc which already handle this scenario correctly by computing or receiving the appropriate frame pointer values. System administrators should ensure their kernels are updated to include these patches to prevent exploitation of this stack-based memory corruption vulnerability.