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. ]
References
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" }
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…