Live › vulnerability › CVE-2026-98641
Go to dashboardOn arm64, a BPF program that throws through a subprogram can leave the frame pointer pointing at a dead stack frame, so a callback passing a local variable address to a helper can overwrite memory in the helper's call chain. The sources describe a kernel panic from this stack corruption; no severity or exploitation details are given.
Summary written from the sources below. Check the originals before acting.
First seen by InfraStack 2026-10-23 21:57 UTC. All times on this page are UTC.
Only arm64 Linux kernels that use BPF programs with exception callbacks (bpf_throw) and subprograms that use their own BPF stack are described as affected. Systems on x86 or powerpc, or on arm64 kernels without BPF exception handling in use, are not described as affected; the sources do not say which kernel versions are impacted.
No product ranges from the sources yet.
uname -r and compare against the kernel version that contains the fix (unknown from sources)uname -m returns aarch64) and whether unprivileged or local users can load BPF programs (sysctl kernel.unprivileged_bpf_disabled)Each row is the first time that source carried this signal. The analyst’s rows are its own findings.
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.
This page as .md · .json · in your agent: get_signal("CVE-2026-98641")
NVD data is provided by NIST and is public domain. Posts quoted belong to their authors.