fkie_cve-2025-37878
Vulnerability from fkie_nvd
Published
2025-05-09 07:16
Modified
2025-05-12 17:32
Severity ?
Summary
In the Linux kernel, the following vulnerability has been resolved: perf/core: Fix WARN_ON(!ctx) in __free_event() for partial init Move the get_ctx(child_ctx) call and the child_event->ctx assignment to occur immediately after the child event is allocated. Ensure that child_event->ctx is non-NULL before any subsequent error path within inherit_event calls free_event(), satisfying the assumptions of the cleanup code. Details: There's no clear Fixes tag, because this bug is a side-effect of multiple interacting commits over time (up to 15 years old), not a single regression. The code initially incremented refcount then assigned context immediately after the child_event was created. Later, an early validity check for child_event was added before the refcount/assignment. Even later, a WARN_ON_ONCE() cleanup check was added, assuming event->ctx is valid if the pmu_ctx is valid. The problem is that the WARN_ON_ONCE() could trigger after the initial check passed but before child_event->ctx was assigned, violating its precondition. The solution is to assign child_event->ctx right after its initial validation. This ensures the context exists for any subsequent checks or cleanup routines, resolving the WARN_ON_ONCE(). To resolve it, defer the refcount update and child_event->ctx assignment directly after child_event->pmu_ctx is set but before checking if the parent event is orphaned. The cleanup routine depends on event->pmu_ctx being non-NULL before it verifies event->ctx is non-NULL. This also maintains the author's original intent of passing in child_ctx to find_get_pmu_context before its refcount/assignment. [ mingo: Expanded the changelog from another email by Gabriel Shahrouzi. ]
Impacted products
Vendor Product Version



{
  "cveTags": [],
  "descriptions": [
    {
      "lang": "en",
      "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nperf/core: Fix WARN_ON(!ctx) in __free_event() for partial init\n\nMove the get_ctx(child_ctx) call and the child_event-\u003ectx assignment to\noccur immediately after the child event is allocated. Ensure that\nchild_event-\u003ectx is non-NULL before any subsequent error path within\ninherit_event calls free_event(), satisfying the assumptions of the\ncleanup code.\n\nDetails:\n\nThere\u0027s no clear Fixes tag, because this bug is a side-effect of\nmultiple interacting commits over time (up to 15 years old), not\na single regression.\n\nThe code initially incremented refcount then assigned context\nimmediately after the child_event was created. Later, an early\nvalidity check for child_event was added before the\nrefcount/assignment. Even later, a WARN_ON_ONCE() cleanup check was\nadded, assuming event-\u003ectx is valid if the pmu_ctx is valid.\nThe problem is that the WARN_ON_ONCE() could trigger after the initial\ncheck passed but before child_event-\u003ectx was assigned, violating its\nprecondition. The solution is to assign child_event-\u003ectx right after\nits initial validation. This ensures the context exists for any\nsubsequent checks or cleanup routines, resolving the WARN_ON_ONCE().\n\nTo resolve it, defer the refcount update and child_event-\u003ectx assignment\ndirectly after child_event-\u003epmu_ctx is set but before checking if the\nparent event is orphaned. The cleanup routine depends on\nevent-\u003epmu_ctx being non-NULL before it verifies event-\u003ectx is\nnon-NULL. This also maintains the author\u0027s original intent of passing\nin child_ctx to find_get_pmu_context before its refcount/assignment.\n\n[ mingo: Expanded the changelog from another email by Gabriel Shahrouzi. ]"
    },
    {
      "lang": "es",
      "value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: perf/core: Arregla WARN_ON(!ctx) en __free_event() para init parcial Mueve la llamada get_ctx(child_ctx) y la asignaci\u00f3n child_event-\u0026gt;ctx para que ocurran inmediatamente despu\u00e9s de que se asigne el evento secundario. Aseg\u00farate de que child_event-\u0026gt;ctx no sea NULL antes de cualquier ruta de error posterior dentro de las llamadas heritage_event a free_event(), satisfaciendo las suposiciones del c\u00f3digo de limpieza. Detalles: No hay una etiqueta Fixes clara, porque este error es un efecto secundario de m\u00faltiples confirmaciones interactivas a lo largo del tiempo (hasta 15 a\u00f1os de antig\u00fcedad), no una sola regresi\u00f3n. El c\u00f3digo inicialmente increment\u00f3 refcount y luego asign\u00f3 contexto inmediatamente despu\u00e9s de que se creara child_event. M\u00e1s tarde, se agreg\u00f3 una comprobaci\u00f3n de validez temprana para child_event antes de refcount/assignment. Incluso m\u00e1s tarde, se agreg\u00f3 una comprobaci\u00f3n de limpieza WARN_ON_ONCE(), asumiendo que event-\u0026gt;ctx es v\u00e1lido si pmu_ctx es v\u00e1lido. El problema radica en que WARN_ON_ONCE() podr\u00eda activarse despu\u00e9s de que se supere la comprobaci\u00f3n inicial, pero antes de que se asignara child_event-\u0026gt;ctx, incumpliendo su precondici\u00f3n. La soluci\u00f3n es asignar child_event-\u0026gt;ctx justo despu\u00e9s de su validaci\u00f3n inicial. Esto garantiza la existencia del contexto para cualquier comprobaci\u00f3n o rutina de limpieza posterior, resolviendo WARN_ON_ONCE(). Para solucionarlo, posponga la actualizaci\u00f3n del recuento de referencias y la asignaci\u00f3n de child_event-\u0026gt;ctx justo despu\u00e9s de que se configure child_event-\u0026gt;pmu_ctx, pero antes de comprobar si el evento principal est\u00e1 hu\u00e9rfano. La rutina de limpieza depende de que event-\u0026gt;pmu_ctx no sea NULL antes de verificar que event-\u0026gt;ctx no sea NULL. Esto tambi\u00e9n mantiene la intenci\u00f3n original del autor de pasar child_ctx a find_get_pmu_context antes de su recuento de referencias/asignaci\u00f3n. [mingo: Registro de cambios ampliado de otro correo electr\u00f3nico de Gabriel Shahrouzi]."
    }
  ],
  "id": "CVE-2025-37878",
  "lastModified": "2025-05-12T17:32:32.760",
  "metrics": {},
  "published": "2025-05-09T07:16:09.020",
  "references": [
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/0ba3a4ab76fd3367b9cb680cad70182c896c795c"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/1fe9b92eede32574dbe05b5bdb6ad666b350bed0"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/90dc6c1e3b200812da8d0aa030e1b7fda8226d0e"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/cb56cd11feabf99e08bc18960700a53322ffcea7"
    }
  ],
  "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
  "vulnStatus": "Awaiting Analysis"
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.


Loading…

Loading…

Loading…

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.


Loading…

Loading…