<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
  <id>https://vulnerability.circl.lu/rss/recent/all/10</id>
  <title>Most recent entries from all</title>
  <updated>2026-09-30T11:33:40.659518+00:00</updated>
  <author>
    <name>Vulnerability-Lookup</name>
    <email>info@circl.lu</email>
  </author>
  <link href="https://vulnerability.circl.lu" rel="alternate"/>
  <generator uri="https://lkiesow.github.io/python-feedgen" version="1.0.0">python-feedgen</generator>
  <subtitle>Contains only the most 10 recent entries.</subtitle>
  <entry>
    <id>https://vulnerability.circl.lu/vuln/cve-2025-38502</id>
    <title>CVE-2025-38502 — bpf: Fix oob access in cgroup local storage</title>
    <updated>2026-09-30T11:33:40.839610+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> Linux, Siemens SIMATIC CN 4100</p>
<p>In the Linux kernel, the following vulnerability has been resolved:</p>
<p>bpf: Fix oob access in cgroup local storage</p>
<p>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:</p>
<p>ctx = container_of(current-&gt;bpf_ctx, struct bpf_cg_run_ctx, run_ctx);
  storage = ctx-&gt;prog_item-&gt;cgroup_storage[stype];</p>
<p>if (stype == BPF_CGROUP_STORAGE_SHARED)
    ptr = &amp;READ_ONCE(storage-&gt;buf)-&gt;data[0];
  else
    ptr = this_cpu_ptr(storage-&gt;percpu_buf);</p>
<p>For the second program which was called from the originally attached
one, this means bpf_get_local_storage() will pick up the former
program's map, not its own. With mismatching sizes, this can result
in an unintended out-of-bounds access.</p>
<p>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.</p></div>
    </content>
    <link href="https://vulnerability.circl.lu/vuln/cve-2025-38502"/>
  </entry>
</feed>
