ghsa-jvvm-77gw-35g5
Vulnerability from github
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. ]
{
"affected": [],
"aliases": [
"CVE-2025-21895"
],
"database_specific": {
"cwe_ids": [],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-04-01T16:15:19Z",
"severity": null
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nperf/core: Order the PMU list to fix warning about unordered pmu_ctx_list\n\nSyskaller triggers a warning due to prev_epc-\u003epmu != next_epc-\u003epmu in\nperf_event_swap_task_ctx_data(). vmcore shows that two lists have the same\nperf_event_pmu_context, but not in the same order.\n\nThe problem is that the order of pmu_ctx_list for the parent is impacted by\nthe time when an event/PMU is added. While the order for a child is\nimpacted by the event order in the pinned_groups and flexible_groups. So\nthe order of pmu_ctx_list in the parent and child may be different.\n\nTo fix this problem, insert the perf_event_pmu_context to its proper place\nafter iteration of the pmu_ctx_list.\n\nThe follow testcase can trigger above warning:\n\n # perf record -e cycles --call-graph lbr -- taskset -c 3 ./a.out \u0026\n # perf stat -e cpu-clock,cs -p xxx // xxx is the pid of a.out\n\n test.c\n\n void main() {\n int count = 0;\n pid_t pid;\n\n printf(\"%d running\\n\", getpid());\n sleep(30);\n printf(\"running\\n\");\n\n pid = fork();\n if (pid == -1) {\n printf(\"fork error\\n\");\n return;\n }\n if (pid == 0) {\n while (1) {\n count++;\n }\n } else {\n while (1) {\n count++;\n }\n }\n }\n\nThe testcase first opens an LBR event, so it will allocate task_ctx_data,\nand then open tracepoint and software events, so the parent context will\nhave 3 different perf_event_pmu_contexts. On inheritance, child ctx will\ninsert the perf_event_pmu_context in another order and the warning will\ntrigger.\n\n[ mingo: Tidied up the changelog. ]",
"id": "GHSA-jvvm-77gw-35g5",
"modified": "2025-04-01T18:30:49Z",
"published": "2025-04-01T18:30:49Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21895"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/2016066c66192a99d9e0ebf433789c490a6785a2"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3e812a70732d84b7873cea61a7f6349b9a9dcbf5"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/7d582eb6e4e100959ba07083d7563453c8c2a343"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f0c3971405cef6892844016aa710121a02da3a23"
}
],
"schema_version": "1.4.0",
"severity": []
}
Sightings
| Author | Source | Type | Date |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or seen somewhere by the user.
- Confirmed: The vulnerability is confirmed from an analyst perspective.
- Exploited: This vulnerability was exploited and seen by the user reporting the sighting.
- Patched: This vulnerability was successfully patched by the user reporting the sighting.
- Not exploited: This vulnerability was not exploited or seen by the user reporting the sighting.
- Not confirmed: The user expresses doubt about the veracity of the vulnerability.
- Not patched: This vulnerability was not successfully patched by the user reporting the sighting.