fkie_cve-2025-21895
Vulnerability from fkie_nvd
Published
2025-04-01 16:15
Modified
2025-04-01 20:26
Severity ?
Summary
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. ]
References
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/2016066c66192a99d9e0ebf433789c490a6785a2
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/3e812a70732d84b7873cea61a7f6349b9a9dcbf5
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/7d582eb6e4e100959ba07083d7563453c8c2a343
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/f0c3971405cef6892844016aa710121a02da3a23
Impacted products
Vendor Product Version


To clipboard 

{
  "cveTags": [],
  "descriptions": [
    {
      "lang": "en",
      "value": "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. ]"
    },
    {
      "lang": "es",
      "value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: perf/core: Ordenar la lista de PMU para corregir la advertencia sobre pmu_ctx_list desordenada Syskaller activa una advertencia debido a prev_epc-\u0026gt;pmu != next_epc-\u0026gt;pmu en perf_event_swap_task_ctx_data(). vmcore muestra que dos listas tienen el mismo perf_event_pmu_context, pero no en el mismo orden. El problema es que el orden de pmu_ctx_list para el padre se ve afectado por el momento en que se agrega un evento/PMU. Mientras que el orden para un hijo se ve afectado por el orden de los eventos en pinned_groups y flexible_groups. Por lo tanto, el orden de pmu_ctx_list en el padre y el hijo puede ser diferente. Para corregir este problema, inserte perf_event_pmu_context en su lugar correcto despu\u00e9s de la iteraci\u00f3n de pmu_ctx_list. El siguiente caso de prueba puede activar la advertencia anterior: # perf record -e cycles --call-graph lbr -- tasket -c 3 ./a.out \u0026amp; # perf stat -e cpu-clock,cs -p xxx // xxx es el pid de a.out test.c void main() { int count = 0; pid_t pid; printf(\"%d en ejecuci\u00f3n\\n\", getpid()); sleep(30); printf(\"en ejecuci\u00f3n\\n\"); pid = fork(); if (pid == -1) { printf(\"fork error\\n\"); return; } if (pid == 0) { while (1) { count++; } } else { while (1) { count++; } } } El caso de prueba primero abre un evento LBR, por lo que asignar\u00e1 task_ctx_data y luego abrir\u00e1 los eventos de tracepoint y software, por lo que el contexto principal tendr\u00e1 3 perf_event_pmu_contexts diferentes. En caso de herencia, el ctx secundario insertar\u00e1 perf_event_pmu_context en otro orden y se activar\u00e1 la advertencia. [mingo: Se orden\u00f3 el registro de cambios.]"
    }
  ],
  "id": "CVE-2025-21895",
  "lastModified": "2025-04-01T20:26:01.990",
  "metrics": {},
  "published": "2025-04-01T16:15:19.883",
  "references": [
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/2016066c66192a99d9e0ebf433789c490a6785a2"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/3e812a70732d84b7873cea61a7f6349b9a9dcbf5"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/7d582eb6e4e100959ba07083d7563453c8c2a343"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/f0c3971405cef6892844016aa710121a02da3a23"
    }
  ],
  "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
  "vulnStatus": "Awaiting Analysis"
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.




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.