CVE-2024-43869
perf: Fix event leak upon exec and file release
Description
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() =======> <NMI> perf_event_overflow() event->pending_sigtrap = ... irq_work_queue(&event->pending_irq) <======= </NMI> 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() =======> <IRQ> perf_pending_irq() //do nothing, rely on pending task work <======= </IRQ> 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.
INFO
Published Date :
Aug. 21, 2024, 1:15 a.m.
Last Modified :
Sept. 26, 2025, 6:36 p.m.
Remotely Exploit :
No
Source :
416baaa9-dc9f-4396-8d5f-8c081fb06d67
CVSS Scores
| Score | Version | Severity | Vector | Exploitability Score | Impact Score | Source |
|---|---|---|---|---|---|---|
| CVSS 3.1 | MEDIUM | [email protected] |
Solution
- Update the affected Linux kernel packages.
- Reboot the system to apply the update.
References to Advisories, Solutions, and Tools
Here, you will find a curated list of external links that provide in-depth
information, practical solutions, and valuable tools related to
CVE-2024-43869.
CWE - Common Weakness Enumeration
While CVE identifies
specific instances of vulnerabilities, CWE categorizes the common flaws or
weaknesses that can lead to vulnerabilities. CVE-2024-43869 is
associated with the following CWEs:
Common Attack Pattern Enumeration and Classification (CAPEC)
Common Attack Pattern Enumeration and Classification
(CAPEC)
stores attack patterns, which are descriptions of the common attributes and
approaches employed by adversaries to exploit the CVE-2024-43869
weaknesses.
We scan GitHub repositories to detect new proof-of-concept exploits. Following list is a collection of public exploits and proof-of-concepts, which have been published on GitHub (sorted by the most recently updated).
Results are limited to the first 15 repositories due to potential performance issues.
The following list is the news that have been mention
CVE-2024-43869 vulnerability anywhere in the article.
The following table lists the changes that have been made to the
CVE-2024-43869 vulnerability over time.
Vulnerability history details can be useful for understanding the evolution of a vulnerability, and for identifying the most recent changes that may impact the vulnerability's severity, exploitability, or other characteristics.
-
Initial Analysis by [email protected]
Sep. 26, 2025
Action Type Old Value New Value Added CVSS V3.1 AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H Added CWE CWE-401 Added CPE Configuration OR *cpe:2.3:o:linux:linux_kernel:6.1:rc8:*:*:*:*:*:* *cpe:2.3:o:linux:linux_kernel:6.1:-:*:*:*:*:*:* *cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* versions from (including) 6.7 up to (excluding) 6.10.3 *cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* versions from (including) 6.2 up to (excluding) 6.6.44 *cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* versions from (including) 5.15.84 up to (excluding) 5.15.165 *cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* versions from (including) 6.0.14 up to (excluding) 6.1 *cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* versions from (including) 6.1.1 up to (excluding) 6.1.103 Added Reference Type kernel.org: https://git.kernel.org/stable/c/104e258a004037bc7dba9f6085c71dad6af57ad4 Types: Patch Added Reference Type kernel.org: https://git.kernel.org/stable/c/3a5465418f5fd970e86a86c7f4075be262682840 Types: Patch Added Reference Type kernel.org: https://git.kernel.org/stable/c/9ad46f1fef421d43cdab3a7d1744b2f43b54dae0 Types: Patch Added Reference Type kernel.org: https://git.kernel.org/stable/c/ed2c202dac55423a52d7e2290f2888bf08b8ee99 Types: Patch Added Reference Type kernel.org: https://git.kernel.org/stable/c/f34d8307a73a18de5320fcc6f40403146d061891 Types: Patch -
CVE Received by 416baaa9-dc9f-4396-8d5f-8c081fb06d67
Aug. 21, 2024
Action Type Old Value New Value Added Description 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() =======> <NMI> perf_event_overflow() event->pending_sigtrap = ... irq_work_queue(&event->pending_irq) <======= </NMI> 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() =======> <IRQ> perf_pending_irq() //do nothing, rely on pending task work <======= </IRQ> 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. Added Reference kernel.org https://git.kernel.org/stable/c/9ad46f1fef421d43cdab3a7d1744b2f43b54dae0 [No types assigned] Added Reference kernel.org https://git.kernel.org/stable/c/ed2c202dac55423a52d7e2290f2888bf08b8ee99 [No types assigned] Added Reference kernel.org https://git.kernel.org/stable/c/104e258a004037bc7dba9f6085c71dad6af57ad4 [No types assigned] Added Reference kernel.org https://git.kernel.org/stable/c/f34d8307a73a18de5320fcc6f40403146d061891 [No types assigned] Added Reference kernel.org https://git.kernel.org/stable/c/3a5465418f5fd970e86a86c7f4075be262682840 [No types assigned]