CVE-2025-21895

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> perf/core: Order the PMU list to fix warning about unordered pmu_ctx_list<br /> <br /> Syskaller triggers a warning due to prev_epc-&gt;pmu != next_epc-&gt;pmu in<br /> perf_event_swap_task_ctx_data(). vmcore shows that two lists have the same<br /> perf_event_pmu_context, but not in the same order.<br /> <br /> The problem is that the order of pmu_ctx_list for the parent is impacted by<br /> the time when an event/PMU is added. While the order for a child is<br /> impacted by the event order in the pinned_groups and flexible_groups. So<br /> the order of pmu_ctx_list in the parent and child may be different.<br /> <br /> To fix this problem, insert the perf_event_pmu_context to its proper place<br /> after iteration of the pmu_ctx_list.<br /> <br /> The follow testcase can trigger above warning:<br /> <br /> # perf record -e cycles --call-graph lbr -- taskset -c 3 ./a.out &amp;<br /> # perf stat -e cpu-clock,cs -p xxx // xxx is the pid of a.out<br /> <br /> test.c<br /> <br /> void main() {<br /> int count = 0;<br /> pid_t pid;<br /> <br /> printf("%d running\n", getpid());<br /> sleep(30);<br /> printf("running\n");<br /> <br /> pid = fork();<br /> if (pid == -1) {<br /> printf("fork error\n");<br /> return;<br /> }<br /> if (pid == 0) {<br /> while (1) {<br /> count++;<br /> }<br /> } else {<br /> while (1) {<br /> count++;<br /> }<br /> }<br /> }<br /> <br /> The testcase first opens an LBR event, so it will allocate task_ctx_data,<br /> and then open tracepoint and software events, so the parent context will<br /> have 3 different perf_event_pmu_contexts. On inheritance, child ctx will<br /> insert the perf_event_pmu_context in another order and the warning will<br /> trigger.<br /> <br /> [ mingo: Tidied up the changelog. ]