<?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://vulnerability.circl.lu</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>Mon, 05 Oct 2026 16:35:25 +0000</lastBuildDate>
    <item>
      <title>CVE-2024-43843 — riscv, bpf: Fix out-of-bounds issue when preparing trampoline image</title>
      <link>https://vulnerability.circl.lu/vuln/cve-2024-43843</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;riscv, bpf: Fix out-of-bounds issue when preparing trampoline image&lt;/p&gt;
&lt;p&gt;We get the size of the trampoline image during the dry run phase and
allocate memory based on that size. The allocated image will then be
populated with instructions during the real patch phase. But after
commit 26ef208c209a (&amp;#34;bpf: Use arch_bpf_trampoline_size&amp;#34;), the `im`
argument is inconsistent in the dry run and real patch phase. This may
cause emit_imm in RV64 to generate a different number of instructions
when generating the &amp;#39;im&amp;#39; address, potentially causing out-of-bounds
issues. Let&amp;#39;s emit the maximum number of instructions for the &amp;#34;im&amp;#34;
address during dry run to fix this problem.&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;riscv, bpf: Fix out-of-bounds issue when preparing trampoline image&lt;/p&gt;
&lt;p&gt;We get the size of the trampoline image during the dry run phase and
allocate memory based on that size. The allocated image will then be
populated with instructions during the real patch phase. But after
commit 26ef208c209a (&amp;#34;bpf: Use arch_bpf_trampoline_size&amp;#34;), the `im`
argument is inconsistent in the dry run and real patch phase. This may
cause emit_imm in RV64 to generate a different number of instructions
when generating the &amp;#39;im&amp;#39; address, potentially causing out-of-bounds
issues. Let&amp;#39;s emit the maximum number of instructions for the &amp;#34;im&amp;#34;
address during dry run to fix this problem.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/cve-2024-43843</guid>
    </item>
  </channel>
</rss>
