GHSA-24F8-F4WM-56GG

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 exit

When a task is scheduled out, pending sigtrap deliveries are deferred to the target task upon resume to userspace via task_work.

However failures while adding an event's callback to the task_work engine are ignored. And since the last call for events exit happen after task work is eventually closed, there is a small window during which pending sigtrap can be queued though ignored, leaking the event refcount addition such as in the following scenario:

TASK A
-----

do_exit()
   exit_task_work(tsk);

   <IRQ>
   perf_event_overflow()
      event->pending_sigtrap = pending_id;
      irq_work_queue(&event->pending_irq);
   </IRQ>
=========> PREEMPTION: TASK A -> TASK B
   event_sched_out()
      event->pending_sigtrap = 0;
      atomic_long_inc_not_zero(&event->refcount)
      // FAILS: task work has exited
      task_work_add(&event->pending_task)
   [...]
   <IRQ WORK>
   perf_pending_irq()
      // early return: event->oncpu = -1
   </IRQ WORK>
   [...]
=========> TASK B -> TASK A
   perf_event_exit_task(tsk)
      perf_event_exit_event()
         free_event()
            WARN(atomic_long_cmpxchg(&event->refcount, 1, 0) != 1)
            // leak event due to unexpected refcount == 2

As a result the event is never released while the task exits.

Fix this with appropriate task_work_add()'s error handling.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-43870"
  ],
  "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 exit\n\nWhen a task is scheduled out, pending sigtrap deliveries are deferred\nto the target task upon resume to userspace via task_work.\n\nHowever failures while adding an event\u0027s callback to the task_work\nengine are ignored. And since the last call for events exit happen\nafter task work is eventually closed, there is a small window during\nwhich pending sigtrap can be queued though ignored, leaking the event\nrefcount addition such as in the following scenario:\n\n    TASK A\n    -----\n\n    do_exit()\n       exit_task_work(tsk);\n\n       \u003cIRQ\u003e\n       perf_event_overflow()\n          event-\u003epending_sigtrap = pending_id;\n          irq_work_queue(\u0026event-\u003epending_irq);\n       \u003c/IRQ\u003e\n    =========\u003e PREEMPTION: TASK A -\u003e TASK B\n       event_sched_out()\n          event-\u003epending_sigtrap = 0;\n          atomic_long_inc_not_zero(\u0026event-\u003erefcount)\n          // FAILS: task work has exited\n          task_work_add(\u0026event-\u003epending_task)\n       [...]\n       \u003cIRQ WORK\u003e\n       perf_pending_irq()\n          // early return: event-\u003eoncpu = -1\n       \u003c/IRQ WORK\u003e\n       [...]\n    =========\u003e TASK B -\u003e TASK A\n       perf_event_exit_task(tsk)\n          perf_event_exit_event()\n             free_event()\n                WARN(atomic_long_cmpxchg(\u0026event-\u003erefcount, 1, 0) != 1)\n                // leak event due to unexpected refcount == 2\n\nAs a result the event is never released while the task exits.\n\nFix this with appropriate task_work_add()\u0027s error handling.",
  "id": "GHSA-24f8-f4wm-56gg",
  "modified": "2025-11-04T00:31:17Z",
  "published": "2024-08-21T03:31:53Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43870"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/05d3fd599594abf79aad4484bccb2b26e1cb0b51"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/2fd5ad3f310de22836cdacae919dd99d758a1f1b"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/3d7a63352a93bdb8a1cdf29606bf617d3ac1c22a"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/67fad724f1b568b356c1065d50df46e6b30eb2f7"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/70882d7fa74f0731492a0d493e8515a4f7131831"
    },
    {
      "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.


Loading…

Loading…

Loading…

Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

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.

Loading…

Detection rules are retrieved from Rulezet.

Loading…

Loading…