GHSA-9VRP-98C8-QQX8

Vulnerability from github – Published: 2024-08-21 03:31 – Updated: 2025-11-04 00:31
VLAI?
Details

In the Linux kernel, the following vulnerability has been resolved:

perf: Fix event leak upon exec and file release

The perf pending task work is never waited upon the matching event release. In the case of a child event, released via free_event() directly, this can potentially result in a leaked event, such as in the following scenario that doesn't even require a weak IRQ work implementation to trigger:

schedule() prepare_task_switch() =======> perf_event_overflow() event->pending_sigtrap = ... irq_work_queue(&event->pending_irq) <======= perf_event_task_sched_out() event_sched_out() event->pending_sigtrap = 0; atomic_long_inc_not_zero(&event->refcount) task_work_add(&event->pending_task) finish_lock_switch() =======> perf_pending_irq() //do nothing, rely on pending task work <=======

begin_new_exec() perf_event_exit_task() perf_event_exit_event() // If is child event free_event() WARN(atomic_long_cmpxchg(&event->refcount, 1, 0) != 1) // event is leaked

Similar scenarios can also happen with perf_event_remove_on_exec() or simply against concurrent perf_event_release().

Fix this with synchonizing against the possibly remaining pending task work while freeing the event, just like is done with remaining pending IRQ work. This means that the pending task callback neither need nor should hold a reference to the event, preventing it from ever beeing freed.

Severity ?
5.5 (Medium)
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2024-43869"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-401"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-08-21T01:15:11Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nperf: Fix event leak upon exec and file release\n\nThe perf pending task work is never waited upon the matching event\nrelease. In the case of a child event, released via free_event()\ndirectly, this can potentially result in a leaked event, such as in the\nfollowing scenario that doesn\u0027t even require a weak IRQ work\nimplementation to trigger:\n\nschedule()\n   prepare_task_switch()\n=======\u003e \u003cNMI\u003e\n      perf_event_overflow()\n         event-\u003epending_sigtrap = ...\n         irq_work_queue(\u0026event-\u003epending_irq)\n\u003c======= \u003c/NMI\u003e\n      perf_event_task_sched_out()\n          event_sched_out()\n              event-\u003epending_sigtrap = 0;\n              atomic_long_inc_not_zero(\u0026event-\u003erefcount)\n              task_work_add(\u0026event-\u003epending_task)\n   finish_lock_switch()\n=======\u003e \u003cIRQ\u003e\n   perf_pending_irq()\n      //do nothing, rely on pending task work\n\u003c======= \u003c/IRQ\u003e\n\nbegin_new_exec()\n   perf_event_exit_task()\n      perf_event_exit_event()\n         // If is child event\n         free_event()\n            WARN(atomic_long_cmpxchg(\u0026event-\u003erefcount, 1, 0) != 1)\n            // event is leaked\n\nSimilar scenarios can also happen with perf_event_remove_on_exec() or\nsimply against concurrent perf_event_release().\n\nFix this with synchonizing against the possibly remaining pending task\nwork while freeing the event, just like is done with remaining pending\nIRQ work. This means that the pending task callback neither need nor\nshould hold a reference to the event, preventing it from ever beeing\nfreed.",
  "id": "GHSA-9vrp-98c8-qqx8",
  "modified": "2025-11-04T00:31:17Z",
  "published": "2024-08-21T03:31:53Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43869"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/104e258a004037bc7dba9f6085c71dad6af57ad4"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/3a5465418f5fd970e86a86c7f4075be262682840"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/9ad46f1fef421d43cdab3a7d1744b2f43b54dae0"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/ed2c202dac55423a52d7e2290f2888bf08b8ee99"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/f34d8307a73a18de5320fcc6f40403146d061891"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.




Sightings

Author Source Type Date

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.



Detection rules are retrieved from Rulezet.