<?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>Wed, 30 Sep 2026 03:40:34 +0000</lastBuildDate>
    <item>
      <title>CVE-2025-38502 — bpf: Fix oob access in cgroup local storage</title>
      <link>https://vulnerability.circl.lu/vuln/cve-2025-38502</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Linux, Siemens SIMATIC CN 4100&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;bpf: Fix oob access in cgroup local storage&lt;/p&gt;
&lt;p&gt;Lonial reported that an out-of-bounds access in cgroup local storage
can be crafted via tail calls. Given two programs each utilizing a
cgroup local storage with a different value size, and one program
doing a tail call into the other. The verifier will validate each of
the indivial programs just fine. However, in the runtime context
the bpf_cg_run_ctx holds an bpf_prog_array_item which contains the
BPF program as well as any cgroup local storage flavor the program
uses. Helpers such as bpf_get_local_storage() pick this up from the
runtime context:&lt;/p&gt;
&lt;p&gt;ctx = container_of(current-&amp;gt;bpf_ctx, struct bpf_cg_run_ctx, run_ctx);
  storage = ctx-&amp;gt;prog_item-&amp;gt;cgroup_storage[stype];&lt;/p&gt;
&lt;p&gt;if (stype == BPF_CGROUP_STORAGE_SHARED)
    ptr = &amp;amp;READ_ONCE(storage-&amp;gt;buf)-&amp;gt;data[0];
  else
    ptr = this_cpu_ptr(storage-&amp;gt;percpu_buf);&lt;/p&gt;
&lt;p&gt;For the second program which was called from the originally attached
one, this means bpf_get_local_storage() will pick up the former
program&amp;#39;s map, not its own. With mismatching sizes, this can result
in an unintended out-of-bounds access.&lt;/p&gt;
&lt;p&gt;To fix this issue, we need to extend bpf_map_owner with an array of
storage_cookie[] to match on i) the exact maps from the original
program if the second program was using bpf_get_local_storage(), or
ii) allow the tail call combination if the second program was not
using any of the cgroup local storage maps.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Linux, Siemens SIMATIC CN 4100&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;bpf: Fix oob access in cgroup local storage&lt;/p&gt;
&lt;p&gt;Lonial reported that an out-of-bounds access in cgroup local storage
can be crafted via tail calls. Given two programs each utilizing a
cgroup local storage with a different value size, and one program
doing a tail call into the other. The verifier will validate each of
the indivial programs just fine. However, in the runtime context
the bpf_cg_run_ctx holds an bpf_prog_array_item which contains the
BPF program as well as any cgroup local storage flavor the program
uses. Helpers such as bpf_get_local_storage() pick this up from the
runtime context:&lt;/p&gt;
&lt;p&gt;ctx = container_of(current-&amp;gt;bpf_ctx, struct bpf_cg_run_ctx, run_ctx);
  storage = ctx-&amp;gt;prog_item-&amp;gt;cgroup_storage[stype];&lt;/p&gt;
&lt;p&gt;if (stype == BPF_CGROUP_STORAGE_SHARED)
    ptr = &amp;amp;READ_ONCE(storage-&amp;gt;buf)-&amp;gt;data[0];
  else
    ptr = this_cpu_ptr(storage-&amp;gt;percpu_buf);&lt;/p&gt;
&lt;p&gt;For the second program which was called from the originally attached
one, this means bpf_get_local_storage() will pick up the former
program&amp;#39;s map, not its own. With mismatching sizes, this can result
in an unintended out-of-bounds access.&lt;/p&gt;
&lt;p&gt;To fix this issue, we need to extend bpf_map_owner with an array of
storage_cookie[] to match on i) the exact maps from the original
program if the second program was using bpf_get_local_storage(), or
ii) allow the tail call combination if the second program was not
using any of the cgroup local storage maps.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/cve-2025-38502</guid>
    </item>
  </channel>
</rss>
