<?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, 28 Sep 2026 06:37:18 +0000</lastBuildDate>
    <item>
      <title>CVE-2026-89580 — bpf: Disable preemption in __bpf_get_stack</title>
      <link>https://vulnerability.circl.lu/vuln/cve-2026-89580</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: Disable preemption in __bpf_get_stack&lt;/p&gt;
&lt;p&gt;get_perf_callchain() returns a per-CPU perf_callchain_entry buffer and
releases its recursion slot via put_callchain_entry() before returning,
so nothing keeps the entry reserved while __bpf_get_stack() consumes
it below.&lt;/p&gt;
&lt;p&gt;A preemptible BPF program (e.g. a non-sleepable raw tracepoint program
on a PREEMPT kernel, which runs under migrate_disable() but not
preempt_disable()) can be scheduled out between obtaining the entry
and the copy. Another task scheduled on the same CPU then reuses the
same per-CPU buffer and overwrites trace-&amp;gt;nr with a larger value.
copy_len is then computed from the inflated trace-&amp;gt;nr and can exceed
the caller&amp;#39;s buffer, causing an out-of-bounds write in the memcpy()
and in the build_id path.&lt;/p&gt;
&lt;p&gt;The rcu_read_lock() taken here alone does not prevent this. It is
only taken on the may_fault path, and under CONFIG_PREEMPT_RCU it does
not disable preemption; it merely keeps perf&amp;#39;s callchain buffer array
alive (freed via call_rcu()) and does nothing to stop another task
from reusing the entry.&lt;/p&gt;
&lt;p&gt;Disable preemption around obtaining the callchain entry and copying
it into the caller&amp;#39;s buffer, so the entry cannot be reused underneath
us and trace-&amp;gt;nr stays bounded by max_depth. Build ID resolution may
fault and is therefore deferred until after preemption is re-enabled;
by then the instruction pointers have already been copied into buf,
so it operates on…&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: Disable preemption in __bpf_get_stack&lt;/p&gt;
&lt;p&gt;get_perf_callchain() returns a per-CPU perf_callchain_entry buffer and
releases its recursion slot via put_callchain_entry() before returning,
so nothing keeps the entry reserved while __bpf_get_stack() consumes
it below.&lt;/p&gt;
&lt;p&gt;A preemptible BPF program (e.g. a non-sleepable raw tracepoint program
on a PREEMPT kernel, which runs under migrate_disable() but not
preempt_disable()) can be scheduled out between obtaining the entry
and the copy. Another task scheduled on the same CPU then reuses the
same per-CPU buffer and overwrites trace-&amp;gt;nr with a larger value.
copy_len is then computed from the inflated trace-&amp;gt;nr and can exceed
the caller&amp;#39;s buffer, causing an out-of-bounds write in the memcpy()
and in the build_id path.&lt;/p&gt;
&lt;p&gt;The rcu_read_lock() taken here alone does not prevent this. It is
only taken on the may_fault path, and under CONFIG_PREEMPT_RCU it does
not disable preemption; it merely keeps perf&amp;#39;s callchain buffer array
alive (freed via call_rcu()) and does nothing to stop another task
from reusing the entry.&lt;/p&gt;
&lt;p&gt;Disable preemption around obtaining the callchain entry and copying
it into the caller&amp;#39;s buffer, so the entry cannot be reused underneath
us and trace-&amp;gt;nr stays bounded by max_depth. Build ID resolution may
fault and is therefore deferred until after preemption is re-enabled;
by then the instruction pointers have already been copied into buf,
so it operates on…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/cve-2026-89580</guid>
    </item>
  </channel>
</rss>
