<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<rss xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/" version="2.0">
  <channel>
    <title>Most recent entries from all</title>
    <link>https://db.gcve.eu</link>
    <description>Contains only the most 10 recent entries.</description>
    <docs>http://www.rssboard.org/rss-specification</docs>
    <generator>python-feedgen</generator>
    <language>en</language>
    <lastBuildDate>Sun, 01 Nov 2026 22:51:22 +0000</lastBuildDate>
    <item>
      <title>CVE-2026-98641 — bpf, arm64: set up the frame pointer for the exception callback</title>
      <link>https://db.gcve.eu/vuln/cve-2026-98641</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Linux&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;bpf, arm64: set up the frame pointer for the exception callback&lt;/p&gt;
&lt;p&gt;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-&amp;gt;fp_used is set, so the callback prologue
does not emit the&lt;/p&gt;
&lt;p&gt;mov x25, sp&lt;/p&gt;
&lt;p&gt;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&amp;#39;s frame
pointer, and since the subprogram never returns it never restores x25
either.&lt;/p&gt;
&lt;p&gt;Stack accesses through BPF_REG_FP are rewritten to be stack pointer
relative, so those still land in the callback&amp;#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&amp;#39;s
frame. That address is below the callback&amp;#39;s stack pointer by then, and
the helper&amp;#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:&lt;/p&gt;
&lt;p&gt;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&lt;/p&gt;
&lt;p&gt;Set ctx-&amp;gt;fp_used on the exception callback path…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Linux&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;bpf, arm64: set up the frame pointer for the exception callback&lt;/p&gt;
&lt;p&gt;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-&amp;gt;fp_used is set, so the callback prologue
does not emit the&lt;/p&gt;
&lt;p&gt;mov x25, sp&lt;/p&gt;
&lt;p&gt;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&amp;#39;s frame
pointer, and since the subprogram never returns it never restores x25
either.&lt;/p&gt;
&lt;p&gt;Stack accesses through BPF_REG_FP are rewritten to be stack pointer
relative, so those still land in the callback&amp;#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&amp;#39;s
frame. That address is below the callback&amp;#39;s stack pointer by then, and
the helper&amp;#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:&lt;/p&gt;
&lt;p&gt;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&lt;/p&gt;
&lt;p&gt;Set ctx-&amp;gt;fp_used on the exception callback path…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://db.gcve.eu/vuln/cve-2026-98641</guid>
    </item>
  </channel>
</rss>
