cve/published/2025/CVE-2025-37878.mbox

From bippy-1.2.0 Mon Sep 17 00:00:00 2001
From: Greg Kroah-Hartman <gregkh@kernel.org>
To: <linux-cve-announce@vger.kernel.org>
Reply-to: <cve@kernel.org>, <linux-kernel@vger.kernel.org>
Subject: CVE-2025-37878: perf/core: Fix WARN_ON(!ctx) in __free_event() for partial init

Description
===========

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. ]

The Linux kernel CVE team has assigned CVE-2025-37878 to this issue.


Affected and fixed versions
===========================

	Fixed in 6.6.89 with commit 1fe9b92eede32574dbe05b5bdb6ad666b350bed0
	Fixed in 6.12.26 with commit 90dc6c1e3b200812da8d0aa030e1b7fda8226d0e
	Fixed in 6.14.5 with commit cb56cd11feabf99e08bc18960700a53322ffcea7
	Fixed in 6.15 with commit 0ba3a4ab76fd3367b9cb680cad70182c896c795c

Please see https://www.kernel.org for a full list of currently supported
kernel versions by the kernel community.

Unaffected versions might change over time as fixes are backported to
older supported kernel versions.  The official CVE entry at
	https://cve.org/CVERecord/?id=CVE-2025-37878
will be updated if fixes are backported, please check that for the most
up to date information about this issue.


Affected files
==============

The file(s) affected by this issue are:
	kernel/events/core.c


Mitigation
==========

The Linux kernel CVE team recommends that you update to the latest
stable kernel version for this, and many other bugfixes.  Individual
changes are never tested alone, but rather are part of a larger kernel
release.  Cherry-picking individual commits is not recommended or
supported by the Linux kernel community at all.  If however, updating to
the latest release is impossible, the individual changes to resolve this
issue can be found at these commits:
	https://git.kernel.org/stable/c/1fe9b92eede32574dbe05b5bdb6ad666b350bed0
	https://git.kernel.org/stable/c/90dc6c1e3b200812da8d0aa030e1b7fda8226d0e
	https://git.kernel.org/stable/c/cb56cd11feabf99e08bc18960700a53322ffcea7
	https://git.kernel.org/stable/c/0ba3a4ab76fd3367b9cb680cad70182c896c795c