https://db.gcve.eu Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Sun, 01 Nov 2026 22:46:38 +0000 https://db.gcve.eu/vuln/certfr-2026-avi-1375 certfr-2026-avi-1375 https://db.gcve.eu/vuln/certfr-2026-avi-1375 https://db.gcve.eu/vuln/fkie_cve-2026-98641 <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>bpf, arm64: set up the frame pointer for the exception callback</p> <p>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-&gt;fp_used is set, so the callback prologue does not emit the</p> <p>mov x25, sp</p> <p>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&#39;s frame pointer, and since the subprogram never returns it never restores x25 either.</p> <p>Stack accesses through BPF_REG_FP are rewritten to be stack pointer relative, so those still land in the callback&#39;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&#39;s frame. That address is below the callback&#39;s stack pointer by then, and the helper&#39;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:</p> <p>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</p> <p>Set ctx-&gt;fp_used on the exception callback path…</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>bpf, arm64: set up the frame pointer for the exception callback</p> <p>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-&gt;fp_used is set, so the callback prologue does not emit the</p> <p>mov x25, sp</p> <p>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&#39;s frame pointer, and since the subprogram never returns it never restores x25 either.</p> <p>Stack accesses through BPF_REG_FP are rewritten to be stack pointer relative, so those still land in the callback&#39;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&#39;s frame. That address is below the callback&#39;s stack pointer by then, and the helper&#39;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:</p> <p>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</p> <p>Set ctx-&gt;fp_used on the exception callback path…</p> https://db.gcve.eu/vuln/fkie_cve-2026-98641 https://db.gcve.eu/vuln/ghsa-rmw7-mmh2-5m8g <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>bpf, arm64: set up the frame pointer for the exception callback</p> <p>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-&gt;fp_used is set, so the callback prologue does not emit the</p> <p>mov x25, sp</p> <p>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&#39;s frame pointer, and since the subprogram never returns it never restores x25 either.</p> <p>Stack accesses through BPF_REG_FP are rewritten to be stack pointer relative, so those still land in the callback&#39;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&#39;s frame. That address is below the callback&#39;s stack pointer by then, and the helper&#39;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:</p> <p>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</p> <p>Set ctx-&gt;fp_used on the exception callback path…</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>bpf, arm64: set up the frame pointer for the exception callback</p> <p>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-&gt;fp_used is set, so the callback prologue does not emit the</p> <p>mov x25, sp</p> <p>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&#39;s frame pointer, and since the subprogram never returns it never restores x25 either.</p> <p>Stack accesses through BPF_REG_FP are rewritten to be stack pointer relative, so those still land in the callback&#39;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&#39;s frame. That address is below the callback&#39;s stack pointer by then, and the helper&#39;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:</p> <p>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</p> <p>Set ctx-&gt;fp_used on the exception callback path…</p> https://db.gcve.eu/vuln/ghsa-rmw7-mmh2-5m8g https://db.gcve.eu/vuln/msrc_cve-2026-98641 msrc_CVE-2026-98641 https://db.gcve.eu/vuln/msrc_cve-2026-98641 https://db.gcve.eu/vuln/ubuntu-cve-2026-98641 <p><strong>Affected:</strong> Ubuntu:16.04:LTS: linux-hwe-edge, Ubuntu:18.04:LTS: linux-aws-5.0, Ubuntu:18.04:LTS: linux-aws-5.3, Ubuntu:18.04:LTS: linux-azure, Ubuntu:18.04:LTS: linux-azure-5.3, Ubuntu:18.04:LTS: linux-azure-edge, Ubuntu:18.04:LTS: linux-gcp, Ubuntu:18.04:LTS: linux-gcp-5.3, Ubuntu:18.04:LTS: linux-gke-4.15, Ubuntu:18.04:LTS: linux-gke-5.4 and 120 more</p> <p>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-&gt;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&#39;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&#39;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&#39;s frame. That address is below the callback&#39;s stack pointer by then, and the helper&#39;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-&gt;fp_used on the exception callback path so that…</p> <p><strong>Affected:</strong> Ubuntu:16.04:LTS: linux-hwe-edge, Ubuntu:18.04:LTS: linux-aws-5.0, Ubuntu:18.04:LTS: linux-aws-5.3, Ubuntu:18.04:LTS: linux-azure, Ubuntu:18.04:LTS: linux-azure-5.3, Ubuntu:18.04:LTS: linux-azure-edge, Ubuntu:18.04:LTS: linux-gcp, Ubuntu:18.04:LTS: linux-gcp-5.3, Ubuntu:18.04:LTS: linux-gke-4.15, Ubuntu:18.04:LTS: linux-gke-5.4 and 120 more</p> <p>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-&gt;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&#39;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&#39;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&#39;s frame. That address is below the callback&#39;s stack pointer by then, and the helper&#39;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-&gt;fp_used on the exception callback path so that…</p> https://db.gcve.eu/vuln/ubuntu-cve-2026-98641