cbcvebase.
CVE-2025-37747
published 2025-05-01

CVE-2025-37747: In the Linux kernel, the following vulnerability has been resolved: perf: Fix hang while freeing sigtrap event Perf can hang while freeing a sigtrap event if a…

PriorityP419medium5.5CVSS 3.1
AVLACLPRLUINSUCNINAH
EPSS
0.18%
7.2th percentile
In the Linux kernel, the following vulnerability has been resolved: perf: Fix hang while freeing sigtrap event Perf can hang while freeing a sigtrap event if a related deferred signal hadn't managed to be sent before the file got closed: perf_event_overflow() task_work_add(perf_pending_task) fput() task_work_add(____fput()) task_work_run() ____fput() perf_release() perf_event_release_kernel() _free_event() perf_pending_task_sync() task_work_cancel() -> FAILED rcuwait_wait_event() Once task_work_run() is running, the list of pending callbacks is removed from the task_struct and from this point on task_work_cancel() can't remove any pending and not yet started work items, hence the task_work_cancel() failure and the hang on rcuwait_wait_event(). Task work could be changed to remove one work at a time, so a work running on the current task can always cancel a pending one, however the wait / wake design is still subject to inverted dependencies when remote targets are involved, as pictured by Oleg: T1 T2 fd = perf_event_open(pid => T2->pid); fd = perf_event_open(pid => T1->pid); close(fd) close(fd) perf_event_overflow() perf_event_overflow() task_work_add(perf_pending_task) task_work_add(perf_pending_task) fput() fput() task_work_add(____fput()) task_work_add(____fput()) task_work_run() task_work_run() ____fput() ____fput() perf_release() perf_release() perf_event_release_kernel() perf_event_release_kernel() _free_event() _free_event() perf_pending_task_sync() perf_pending_task_sync() rcuwait_wait_event() rcuwait_wait_event() Therefore the only option left is to acquire the event reference count upon queueing the perf task work and release it from the task work, just like it was done before 3a5465418f5f ("perf: Fix event leak upon exec and file release") but without the leaks it fixed. Some adjustments are necessary to make it work: * A child event might dereference its parent upon freeing. Care must be taken to release the parent last. * Some places ass

Affected

35 ranges· showing 25
VendorProductVersion rangeFixed in
debianlinux< linux 6.12.25-1 (forky)linux 6.12.25-1 (forky)
linuxlinux
linuxlinux
linuxlinux
linuxlinux
linuxlinux
linuxlinux>= 3a5465418f5fd970e86a86c7f4075be262682840 < fa1827fa968c0674e9b6fca223fa9fb4da4493ebfa1827fa968c0674e9b6fca223fa9fb4da4493eb
linuxlinux>= 3a5465418f5fd970e86a86c7f4075be262682840 < 665b87b8f8b3aeb49083ef3b65c4953e7753fc12665b87b8f8b3aeb49083ef3b65c4953e7753fc12
linuxlinux>= 3a5465418f5fd970e86a86c7f4075be262682840 < 1267bd38f161c1a27d9b722de017027167a225a01267bd38f161c1a27d9b722de017027167a225a0
linuxlinux>= 3a5465418f5fd970e86a86c7f4075be262682840 < 56799bc035658738f362acec3e7647bb84e6893356799bc035658738f362acec3e7647bb84e68933
linuxlinux>= 5.15.165 < 5.165.16
linuxlinux>= 6.1.103 < 6.26.2
linuxlinux>= 6.10.3 < 6.116.11
linuxlinux>= 6.6.44 < 6.76.7
linuxlinux_kernel
linuxlinux_kernel>= 0 < 6.12.25-16.12.25-1
linuxlinux_kernel>= 0 < 6.12.25-16.12.25-1
linuxlinux_kernel>= 0 < 6.14.0-22.226.14.0-22.22
linuxlinux_kernel>= 5.15.165 < 5.165.16
linuxlinux_kernel>= 6.1.103 < 6.26.2
linuxlinux_kernel>= 6.10.3 < 6.12.246.12.24
linuxlinux_kernel>= 6.13 < 6.13.126.13.12
linuxlinux_kernel>= 6.14 < 6.14.36.14.3
linuxlinux_kernel>= 6.6.44 < 6.76.7
msrcazl3_kernel_6.6.104.2-4_on_azure_linux_3.0

CVSS provenance

nvdv3.15.5MEDIUMCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
osv5.5MEDIUM
vendor_debian5.5MEDIUM
vendor_msrc5.5MEDIUM
vendor_redhat5.5MEDIUM
Stop checking back — get the weekly exploitation signal.

Every Monday: what got weaponized or added to CISA KEV in the last seven days — each CVE cross-linked to its PoC, Nuclei template, and detection rule. Free, one email a week, unsubscribe in one click.