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. ]
CVE-2025-37878 is a kernel-level vulnerability in the Linux performance monitoring subsystem (perf). This flaw can lead to a kernel panic or denial-of-service (DoS) due to a race condition in the event context handling during the initialization of child events, potentially allowing for system instability. Successful exploitation could disrupt critical system functions.
Step 1: Event Creation: A user-space process initiates the creation of a performance monitoring event, potentially through the perf_event_open() system call.
Step 2: Child Event Allocation: The kernel allocates memory for a child event, a component of the performance monitoring framework.
Step 3: PMU Context Assignment: The pmu_ctx (Performance Monitoring Unit context) is assigned to the child event.
Step 4: Race Condition Window: A window of vulnerability exists where the child event is allocated, pmu_ctx is set, but the child_event->ctx (event context) is not yet assigned. During this window, other kernel operations could trigger the WARN_ON_ONCE() check.
Step 5: WARN_ON_ONCE Trigger: If the WARN_ON_ONCE() check is triggered before child_event->ctx is assigned, it detects an invalid state, leading to a kernel warning. In some scenarios, this can lead to a kernel panic or other memory corruption.
Step 6: Cleanup/Freeing: The cleanup routine, __free_event(), is called. Because child_event->ctx may not have been assigned, the cleanup routine's assumptions are violated, potentially leading to a use-after-free or other memory corruption.
Step 7: Kernel Panic/DoS: The memory corruption or invalid state results in a kernel panic, system crash, or denial of service.
The vulnerability resides within the perf/core subsystem, specifically in the __free_event() function. The root cause is a race condition stemming from the order of operations during child event initialization. The code initially incremented a reference count and assigned the context immediately after the child event was created. Later, a validity check was added before the refcount/assignment. A WARN_ON_ONCE() check was subsequently introduced, assuming the event's context is valid if the PMU context is valid. The flaw occurs when the initial check passes, but the context assignment happens after, leading to a violation of the WARN_ON_ONCE() precondition. This can result in a use-after-free condition or other memory corruption issues, ultimately leading to a kernel panic or DoS.