<?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>Sun, 04 Oct 2026 12:57:17 +0000</lastBuildDate>
    <item>
      <title>CVE-2025-21895 — perf/core: Order the PMU list to fix warning about unordered pmu_ctx_list</title>
      <link>https://vulnerability.circl.lu/vuln/cve-2025-21895</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;perf/core: Order the PMU list to fix warning about unordered pmu_ctx_list&lt;/p&gt;
&lt;p&gt;Syskaller triggers a warning due to prev_epc-&amp;gt;pmu != next_epc-&amp;gt;pmu in
perf_event_swap_task_ctx_data(). vmcore shows that two lists have the same
perf_event_pmu_context, but not in the same order.&lt;/p&gt;
&lt;p&gt;The problem is that the order of pmu_ctx_list for the parent is impacted by
the time when an event/PMU is added. While the order for a child is
impacted by the event order in the pinned_groups and flexible_groups. So
the order of pmu_ctx_list in the parent and child may be different.&lt;/p&gt;
&lt;p&gt;To fix this problem, insert the perf_event_pmu_context to its proper place
after iteration of the pmu_ctx_list.&lt;/p&gt;
&lt;p&gt;The follow testcase can trigger above warning:&lt;/p&gt;
&lt;p&gt;# perf record -e cycles --call-graph lbr -- taskset -c 3 ./a.out &amp;amp;
 # perf stat -e cpu-clock,cs -p xxx // xxx is the pid of a.out&lt;/p&gt;
&lt;p&gt;test.c&lt;/p&gt;
&lt;p&gt;void main() {
        int count = 0;
        pid_t pid;&lt;/p&gt;
&lt;p&gt;printf(&amp;#34;%d running\n&amp;#34;, getpid());
        sleep(30);
        printf(&amp;#34;running\n&amp;#34;);&lt;/p&gt;
&lt;p&gt;pid = fork();
        if (pid == -1) {
                printf(&amp;#34;fork error\n&amp;#34;);
                return;
        }
        if (pid == 0) {
                while (1) {
                        count++;
                }
        } else {
                while (1) {
                        count++;
                }
        }
 }&lt;/p&gt;
&lt;p&gt;The testcase first opens an LBR event, so it will allocate task_ctx_data,
and then open…&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;perf/core: Order the PMU list to fix warning about unordered pmu_ctx_list&lt;/p&gt;
&lt;p&gt;Syskaller triggers a warning due to prev_epc-&amp;gt;pmu != next_epc-&amp;gt;pmu in
perf_event_swap_task_ctx_data(). vmcore shows that two lists have the same
perf_event_pmu_context, but not in the same order.&lt;/p&gt;
&lt;p&gt;The problem is that the order of pmu_ctx_list for the parent is impacted by
the time when an event/PMU is added. While the order for a child is
impacted by the event order in the pinned_groups and flexible_groups. So
the order of pmu_ctx_list in the parent and child may be different.&lt;/p&gt;
&lt;p&gt;To fix this problem, insert the perf_event_pmu_context to its proper place
after iteration of the pmu_ctx_list.&lt;/p&gt;
&lt;p&gt;The follow testcase can trigger above warning:&lt;/p&gt;
&lt;p&gt;# perf record -e cycles --call-graph lbr -- taskset -c 3 ./a.out &amp;amp;
 # perf stat -e cpu-clock,cs -p xxx // xxx is the pid of a.out&lt;/p&gt;
&lt;p&gt;test.c&lt;/p&gt;
&lt;p&gt;void main() {
        int count = 0;
        pid_t pid;&lt;/p&gt;
&lt;p&gt;printf(&amp;#34;%d running\n&amp;#34;, getpid());
        sleep(30);
        printf(&amp;#34;running\n&amp;#34;);&lt;/p&gt;
&lt;p&gt;pid = fork();
        if (pid == -1) {
                printf(&amp;#34;fork error\n&amp;#34;);
                return;
        }
        if (pid == 0) {
                while (1) {
                        count++;
                }
        } else {
                while (1) {
                        count++;
                }
        }
 }&lt;/p&gt;
&lt;p&gt;The testcase first opens an LBR event, so it will allocate task_ctx_data,
and then open…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/cve-2025-21895</guid>
    </item>
  </channel>
</rss>
