fkie_cve-2022-50118
Vulnerability from fkie_nvd
Published
2025-06-18 11:15
Modified
2025-06-18 13:47
Severity ?
Summary
In the Linux kernel, the following vulnerability has been resolved: powerpc/perf: Optimize clearing the pending PMI and remove WARN_ON for PMI check in power_pmu_disable commit 2c9ac51b850d ("powerpc/perf: Fix PMU callbacks to clear pending PMI before resetting an overflown PMC") added a new function "pmi_irq_pending" in hw_irq.h. This function is to check if there is a PMI marked as pending in Paca (PACA_IRQ_PMI).This is used in power_pmu_disable in a WARN_ON. The intention here is to provide a warning if there is PMI pending, but no counter is found overflown. During some of the perf runs, below warning is hit: WARNING: CPU: 36 PID: 0 at arch/powerpc/perf/core-book3s.c:1332 power_pmu_disable+0x25c/0x2c0 Modules linked in: ----- NIP [c000000000141c3c] power_pmu_disable+0x25c/0x2c0 LR [c000000000141c8c] power_pmu_disable+0x2ac/0x2c0 Call Trace: [c000000baffcfb90] [c000000000141c8c] power_pmu_disable+0x2ac/0x2c0 (unreliable) [c000000baffcfc10] [c0000000003e2f8c] perf_pmu_disable+0x4c/0x60 [c000000baffcfc30] [c0000000003e3344] group_sched_out.part.124+0x44/0x100 [c000000baffcfc80] [c0000000003e353c] __perf_event_disable+0x13c/0x240 [c000000baffcfcd0] [c0000000003dd334] event_function+0xc4/0x140 [c000000baffcfd20] [c0000000003d855c] remote_function+0x7c/0xa0 [c000000baffcfd50] [c00000000026c394] flush_smp_call_function_queue+0xd4/0x300 [c000000baffcfde0] [c000000000065b24] smp_ipi_demux_relaxed+0xa4/0x100 [c000000baffcfe20] [c0000000000cb2b0] xive_muxed_ipi_action+0x20/0x40 [c000000baffcfe40] [c000000000207c3c] __handle_irq_event_percpu+0x8c/0x250 [c000000baffcfee0] [c000000000207e2c] handle_irq_event_percpu+0x2c/0xa0 [c000000baffcff10] [c000000000210a04] handle_percpu_irq+0x84/0xc0 [c000000baffcff40] [c000000000205f14] generic_handle_irq+0x54/0x80 [c000000baffcff60] [c000000000015740] __do_irq+0x90/0x1d0 [c000000baffcff90] [c000000000016990] __do_IRQ+0xc0/0x140 [c0000009732f3940] [c000000bafceaca8] 0xc000000bafceaca8 [c0000009732f39d0] [c000000000016b78] do_IRQ+0x168/0x1c0 [c0000009732f3a00] [c0000000000090c8] hardware_interrupt_common_virt+0x218/0x220 This means that there is no PMC overflown among the active events in the PMU, but there is a PMU pending in Paca. The function "any_pmc_overflown" checks the PMCs on active events in cpuhw->n_events. Code snippet: <<>> if (any_pmc_overflown(cpuhw)) clear_pmi_irq_pending(); else WARN_ON(pmi_irq_pending()); <<>> Here the PMC overflown is not from active event. Example: When we do perf record, default cycles and instructions will be running on PMC6 and PMC5 respectively. It could happen that overflowed event is currently not active and pending PMI is for the inactive event. Debug logs from trace_printk: <<>> any_pmc_overflown: idx is 5: pmc value is 0xd9a power_pmu_disable: PMC1: 0x0, PMC2: 0x0, PMC3: 0x0, PMC4: 0x0, PMC5: 0xd9a, PMC6: 0x80002011 <<>> Here active PMC (from idx) is PMC5 , but overflown PMC is PMC6(0x80002011). When we handle PMI interrupt for such cases, if the PMC overflown is from inactive event, it will be ignored. Reference commit: commit bc09c219b2e6 ("powerpc/perf: Fix finding overflowed PMC in interrupt") Patch addresses two changes: 1) Fix 1 : Removal of warning ( WARN_ON(pmi_irq_pending()); ) We were printing warning if no PMC is found overflown among active PMU events, but PMI pending in PACA. But this could happen in cases where PMC overflown is not in active PMC. An inactive event could have caused the overflow. Hence the warning is not needed. To know pending PMI is from an inactive event, we need to loop through all PMC's which will cause more SPR reads via mfspr and increase in context switch. Also in existing function: perf_event_interrupt, already we ignore PMI's overflown when it is from an inactive PMC. 2) Fix 2: optimization in clearing pending PMI. Currently we check for any active PMC overflown before clearing PMI pending in Paca. This is causing additional SP ---truncated---
References
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/0a24ea26c3278216642a43291df7976a73a0a7ee
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/7e83af3dd4a3afca8f83ffde518cafd52f45b830
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/875b2bf469d094754ac2ba9af91dcd529eb12bf6
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/87b1a9175f08313f40fcb6d6dc536dbe451090eb
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/890005a7d98f7452cfe86dcfb2aeeb7df01132ce
Impacted products
Vendor Product Version


To clipboard 

{
  "cveTags": [],
  "descriptions": [
    {
      "lang": "en",
      "value": "In the Linux kernel, the following vulnerability has been resolved:\n\npowerpc/perf: Optimize clearing the pending PMI and remove WARN_ON for PMI check in power_pmu_disable\n\ncommit 2c9ac51b850d (\"powerpc/perf: Fix PMU callbacks to clear\npending PMI before resetting an overflown PMC\") added a new\nfunction \"pmi_irq_pending\" in hw_irq.h. This function is to check\nif there is a PMI marked as pending in Paca (PACA_IRQ_PMI).This is\nused in power_pmu_disable in a WARN_ON. The intention here is to\nprovide a warning if there is PMI pending, but no counter is found\noverflown.\n\nDuring some of the perf runs, below warning is hit:\n\nWARNING: CPU: 36 PID: 0 at arch/powerpc/perf/core-book3s.c:1332 power_pmu_disable+0x25c/0x2c0\n Modules linked in:\n -----\n\n NIP [c000000000141c3c] power_pmu_disable+0x25c/0x2c0\n LR [c000000000141c8c] power_pmu_disable+0x2ac/0x2c0\n Call Trace:\n [c000000baffcfb90] [c000000000141c8c] power_pmu_disable+0x2ac/0x2c0 (unreliable)\n [c000000baffcfc10] [c0000000003e2f8c] perf_pmu_disable+0x4c/0x60\n [c000000baffcfc30] [c0000000003e3344] group_sched_out.part.124+0x44/0x100\n [c000000baffcfc80] [c0000000003e353c] __perf_event_disable+0x13c/0x240\n [c000000baffcfcd0] [c0000000003dd334] event_function+0xc4/0x140\n [c000000baffcfd20] [c0000000003d855c] remote_function+0x7c/0xa0\n [c000000baffcfd50] [c00000000026c394] flush_smp_call_function_queue+0xd4/0x300\n [c000000baffcfde0] [c000000000065b24] smp_ipi_demux_relaxed+0xa4/0x100\n [c000000baffcfe20] [c0000000000cb2b0] xive_muxed_ipi_action+0x20/0x40\n [c000000baffcfe40] [c000000000207c3c] __handle_irq_event_percpu+0x8c/0x250\n [c000000baffcfee0] [c000000000207e2c] handle_irq_event_percpu+0x2c/0xa0\n [c000000baffcff10] [c000000000210a04] handle_percpu_irq+0x84/0xc0\n [c000000baffcff40] [c000000000205f14] generic_handle_irq+0x54/0x80\n [c000000baffcff60] [c000000000015740] __do_irq+0x90/0x1d0\n [c000000baffcff90] [c000000000016990] __do_IRQ+0xc0/0x140\n [c0000009732f3940] [c000000bafceaca8] 0xc000000bafceaca8\n [c0000009732f39d0] [c000000000016b78] do_IRQ+0x168/0x1c0\n [c0000009732f3a00] [c0000000000090c8] hardware_interrupt_common_virt+0x218/0x220\n\nThis means that there is no PMC overflown among the active events\nin the PMU, but there is a PMU pending in Paca. The function\n\"any_pmc_overflown\" checks the PMCs on active events in\ncpuhw-\u003en_events. Code snippet:\n\n\u003c\u003c\u003e\u003e\nif (any_pmc_overflown(cpuhw))\n \tclear_pmi_irq_pending();\n else\n \tWARN_ON(pmi_irq_pending());\n\u003c\u003c\u003e\u003e\n\nHere the PMC overflown is not from active event. Example: When we do\nperf record, default cycles and instructions will be running on PMC6\nand PMC5 respectively. It could happen that overflowed event is currently\nnot active and pending PMI is for the inactive event. Debug logs from\ntrace_printk:\n\n\u003c\u003c\u003e\u003e\nany_pmc_overflown: idx is 5: pmc value is 0xd9a\npower_pmu_disable: PMC1: 0x0, PMC2: 0x0, PMC3: 0x0, PMC4: 0x0, PMC5: 0xd9a, PMC6: 0x80002011\n\u003c\u003c\u003e\u003e\n\nHere active PMC (from idx) is PMC5 , but overflown PMC is PMC6(0x80002011).\nWhen we handle PMI interrupt for such cases, if the PMC overflown is\nfrom inactive event, it will be ignored. Reference commit:\ncommit bc09c219b2e6 (\"powerpc/perf: Fix finding overflowed PMC in interrupt\")\n\nPatch addresses two changes:\n1) Fix 1 : Removal of warning ( WARN_ON(pmi_irq_pending()); )\n   We were printing warning if no PMC is found overflown among active PMU\n   events, but PMI pending in PACA. But this could happen in cases where\n   PMC overflown is not in active PMC. An inactive event could have caused\n   the overflow. Hence the warning is not needed. To know pending PMI is\n   from an inactive event, we need to loop through all PMC\u0027s which will\n   cause more SPR reads via mfspr and increase in context switch. Also in\n   existing function: perf_event_interrupt, already we ignore PMI\u0027s\n   overflown when it is from an inactive PMC.\n\n2) Fix 2: optimization in clearing pending PMI.\n   Currently we check for any active PMC overflown before clearing PMI\n   pending in Paca. This is causing additional SP\n---truncated---"
    },
    {
      "lang": "es",
      "value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: powerpc/perf: Optimizar la limpieza del PMI pendiente y eliminar WARN_ON para la comprobaci\u00f3n de PMI en power_pmu_disable, confirmaci\u00f3n 2c9ac51b850d (\"powerpc/perf: Corregir las devoluciones de llamada de PMU para limpiar el PMI pendiente antes de restablecer un PMC desbordado\"). Se a\u00f1adi\u00f3 la funci\u00f3n \"pmi_irq_pending\" en hw_irq.h. Esta funci\u00f3n comprueba si hay un PMI marcado como pendiente en Paca (PACA_IRQ_PMI). Se utiliza en power_pmu_disable en un WARN_ON. El objetivo es emitir una advertencia si hay un PMI pendiente, pero no se encuentra ning\u00fan contador desbordado. Durante algunas ejecuciones de rendimiento, se muestra la siguiente advertencia: ADVERTENCIA: CPU: 36 PID: 0 en arch/powerpc/perf/core-book3s.c:1332 power_pmu_disable+0x25c/0x2c0 M\u00f3dulos vinculados: ----- NIP [c000000000141c3c] power_pmu_disable+0x25c/0x2c0 LR [c000000000141c8c] power_pmu_disable+0x2ac/0x2c0 Rastreo de llamadas: [c000000baffcfb90] [c000000000141c8c] power_pmu_disable+0x2ac/0x2c0 (unreliable) [c000000baffcfc10] [c0000000003e2f8c] perf_pmu_disable+0x4c/0x60 [c000000baffcfc30] [c0000000003e3344] group_sched_out.part.124+0x44/0x100 [c000000baffcfc80] [c0000000003e353c] __perf_event_disable+0x13c/0x240 [c000000baffcfcd0] [c0000000003dd334] event_function+0xc4/0x140 [c000000baffcfd20] [c0000000003d855c] remote_function+0x7c/0xa0 [c000000baffcfd50] [c00000000026c394] flush_smp_call_function_queue+0xd4/0x300 [c000000baffcfde0] [c000000000065b24] smp_ipi_demux_relaxed+0xa4/0x100 [c000000baffcfe20] [c0000000000cb2b0] xive_muxed_ipi_action+0x20/0x40 [c000000baffcfe40] [c000000000207c3c] __handle_irq_event_percpu+0x8c/0x250 [c000000baffcfee0] [c000000000207e2c] handle_irq_event_percpu+0x2c/0xa0 [c000000baffcff10] [c000000000210a04] handle_percpu_irq+0x84/0xc0 [c000000baffcff40] [c000000000205f14] generic_handle_irq+0x54/0x80 [c000000baffcff60] [c000000000015740] __do_irq+0x90/0x1d0 [c000000baffcff90] [c000000000016990] __do_IRQ+0xc0/0x140 [c0000009732f3940] [c000000bafceaca8] 0xc000000bafceaca8 [c0000009732f39d0] [c000000000016b78] do_IRQ+0x168/0x1c0 [c0000009732f3a00] [c0000000000090c8] hardware_interrupt_common_virt+0x218/0x220 Esto significa que no hay ning\u00fan PMC desbordado entre los eventos activos en la PMU, pero hay una PMU pendiente en Paca. La funci\u00f3n \"any_pmc_overflown\" comprueba los PMC en los eventos activos en cpuhw-\u0026gt;n_events. Fragmento de c\u00f3digo: \u0026lt;\u0026lt;\u0026gt;\u0026gt; if (any_pmc_overflown(cpuhw)) clear_pmi_irq_pending(); else WARN_ON(pmi_irq_pending()); \u0026lt;\u0026lt;\u0026gt;\u0026gt; Aqu\u00ed, el PMC desbordado no proviene del evento activo. Ejemplo: Al realizar un registro de rendimiento, los ciclos e instrucciones predeterminados se ejecutar\u00e1n en PMC6 y PMC5 respectivamente. Podr\u00eda ocurrir que el evento desbordado no est\u00e9 activo y que el PMI pendiente corresponda al evento inactivo. Registros de depuraci\u00f3n de trace_printk: \u0026lt;\u0026lt;\u0026gt;\u0026gt; any_pmc_overflown: idx es 5: el valor de pmc es 0xd9a power_pmu_disable: PMC1: 0x0, PMC2: 0x0, PMC3: 0x0, PMC4: 0x0, PMC5: 0xd9a, PMC6: 0x80002011 \u0026lt;\u0026lt;\u0026gt;\u0026gt; Aqu\u00ed, el PMC activo (de idx) es PMC5, pero el PMC desbordado es PMC6(0x80002011). Cuando manejamos la interrupci\u00f3n de PMI para tales casos, si el PMC desbordado proviene de un evento inactivo, ser\u00e1 ignorado. Referencia de confirmaci\u00f3n: confirmaci\u00f3n bc09c219b2e6 (\"powerpc/perf: Correcci\u00f3n de encontrar PMC desbordado en la interrupci\u00f3n\") El parche aborda dos cambios: 1) Correcci\u00f3n 1: Eliminaci\u00f3n de la advertencia ( WARN_ON(pmi_irq_pending()); ) Est\u00e1bamos imprimiendo una advertencia si no se encontraba ning\u00fan PMC desbordado entre los eventos PMU activos, pero s\u00ed PMI pendiente en PACA. Pero esto podr\u00eda suceder en casos donde el PMC desbordado no est\u00e1 en el PMC activo. Un evento inactivo podr\u00eda haber causado el desbordamiento. Por lo tanto, la advertencia no es necesaria. Para saber si el PMI pendiente proviene de un evento inactivo, necesitamos recorrer todos los PMC, lo que causar\u00e1 m\u00e1s lecturas de SPR a trav\u00e9s de mfspr y aumentar\u00e1 el cambio de contexto. Adem\u00e1s, en la funci\u00f3n existente: --- trunca"
    }
  ],
  "id": "CVE-2022-50118",
  "lastModified": "2025-06-18T13:47:40.833",
  "metrics": {},
  "published": "2025-06-18T11:15:41.477",
  "references": [
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/0a24ea26c3278216642a43291df7976a73a0a7ee"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/7e83af3dd4a3afca8f83ffde518cafd52f45b830"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/875b2bf469d094754ac2ba9af91dcd529eb12bf6"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/87b1a9175f08313f40fcb6d6dc536dbe451090eb"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/890005a7d98f7452cfe86dcfb2aeeb7df01132ce"
    }
  ],
  "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.