ghsa-h3xh-892p-rrrq
Vulnerability from github
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. ]
{
"affected": [],
"aliases": [
"CVE-2025-37878"
],
"database_specific": {
"cwe_ids": [],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-05-09T07:16:09Z",
"severity": null
},
"details": "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. ]",
"id": "GHSA-h3xh-892p-rrrq",
"modified": "2025-05-09T09:33:20Z",
"published": "2025-05-09T09:33:20Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37878"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/0ba3a4ab76fd3367b9cb680cad70182c896c795c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1fe9b92eede32574dbe05b5bdb6ad666b350bed0"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/90dc6c1e3b200812da8d0aa030e1b7fda8226d0e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/cb56cd11feabf99e08bc18960700a53322ffcea7"
}
],
"schema_version": "1.4.0",
"severity": []
}
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.