{"resultsPerPage":1,"startIndex":0,"totalResults":1,"format":"NVD_CVE","version":"2.0","timestamp":"2026-05-12T00:02:33.151","vulnerabilities":[{"cve":{"id":"CVE-2025-37878","sourceIdentifier":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","published":"2025-05-09T07:16:09.020","lastModified":"2026-01-02T16:15:54.233","vulnStatus":"Modified","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->ctx assignment to\noccur immediately after the child event is allocated. Ensure that\nchild_event->ctx 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's 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->ctx 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->ctx was assigned, violating its\nprecondition. The solution is to assign child_event->ctx 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->ctx assignment\ndirectly after child_event->pmu_ctx is set but before checking if the\nparent event is orphaned. The cleanup routine depends on\nevent->pmu_ctx being non-NULL before it verifies event->ctx is\nnon-NULL. This also maintains the author's 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ón child_event->ctx para que ocurran inmediatamente después de que se asigne el evento secundario. Asegúrate de que child_event->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ódigo de limpieza. Detalles: No hay una etiqueta Fixes clara, porque este error es un efecto secundario de múltiples confirmaciones interactivas a lo largo del tiempo (hasta 15 años de antigüedad), no una sola regresión. El código inicialmente incrementó refcount y luego asignó contexto inmediatamente después de que se creara child_event. Más tarde, se agregó una comprobación de validez temprana para child_event antes de refcount/assignment. Incluso más tarde, se agregó una comprobación de limpieza WARN_ON_ONCE(), asumiendo que event->ctx es válido si pmu_ctx es válido. El problema radica en que WARN_ON_ONCE() podría activarse después de que se supere la comprobación inicial, pero antes de que se asignara child_event->ctx, incumpliendo su precondición. La solución es asignar child_event->ctx justo después de su validación inicial. Esto garantiza la existencia del contexto para cualquier comprobación o rutina de limpieza posterior, resolviendo WARN_ON_ONCE(). Para solucionarlo, posponga la actualización del recuento de referencias y la asignación de child_event->ctx justo después de que se configure child_event->pmu_ctx, pero antes de comprobar si el evento principal está huérfano. La rutina de limpieza depende de que event->pmu_ctx no sea NULL antes de verificar que event->ctx no sea NULL. Esto también mantiene la intención original del autor de pasar child_ctx a find_get_pmu_context antes de su recuento de referencias/asignación. [mingo: Registro de cambios ampliado de otro correo electrónico de Gabriel Shahrouzi]."}],"metrics":{"cvssMetricV31":[{"source":"nvd@nist.gov","type":"Primary","cvssData":{"version":"3.1","vectorString":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H","baseScore":5.5,"baseSeverity":"MEDIUM","attackVector":"LOCAL","attackComplexity":"LOW","privilegesRequired":"LOW","userInteraction":"NONE","scope":"UNCHANGED","confidentialityImpact":"NONE","integrityImpact":"NONE","availabilityImpact":"HIGH"},"exploitabilityScore":1.8,"impactScore":3.6}]},"weaknesses":[{"source":"nvd@nist.gov","type":"Primary","description":[{"lang":"en","value":"CWE-617"}]}],"configurations":[{"nodes":[{"operator":"OR","negate":false,"cpeMatch":[{"vulnerable":true,"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionEndExcluding":"6.6.89","matchCriteriaId":"4D51CA5E-345A-4098-B85D-3F2BED7BF3A0"},{"vulnerable":true,"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionStartIncluding":"6.7","versionEndExcluding":"6.12.26","matchCriteriaId":"22F52099-F422-4D19-8283-45F9F9BF4392"},{"vulnerable":true,"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionStartIncluding":"6.13","versionEndExcluding":"6.14.5","matchCriteriaId":"6B25CA7E-4CD0-46DB-B4EF-13A3516071FB"},{"vulnerable":true,"criteria":"cpe:2.3:o:linux:linux_kernel:6.15:rc1:*:*:*:*:*:*","matchCriteriaId":"8D465631-2980-487A-8E65-40AE2B9F8ED1"}]}]}],"references":[{"url":"https://git.kernel.org/stable/c/0ba3a4ab76fd3367b9cb680cad70182c896c795c","source":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","tags":["Patch"]},{"url":"https://git.kernel.org/stable/c/90dc6c1e3b200812da8d0aa030e1b7fda8226d0e","source":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","tags":["Patch"]},{"url":"https://git.kernel.org/stable/c/cb56cd11feabf99e08bc18960700a53322ffcea7","source":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","tags":["Patch"]}]}}]}