CVE Catalog

CVE-2025-37747

MediumCVSS 5.5
Published: Updated: Translated: NVD NIST

Exploitation Probability (EPSS)

Low risk
0.25%

16th percentile - higher than 16% of all known CVEs

Summary

A bug in the Linux kernel's perf subsystem was fixed that could cause a hang while freeing a sigtrap event. The issue occurred when a related deferred signal was not sent before the file was closed, leading to task_work_cancel() failure and a hang on rcuwait_wait_event(). The fix acquires an event reference when queueing perf task work and releases it from the task work, with care taken for child and parent event release ordering.

Risk Assessment

The vulnerability can cause processes or the entire system to hang when closing files associated with perf events, potentially enabling a denial-of-service attack. Organizations using the perf subsystem in the Linux kernel are exposed to operational disruptions.

Recommendation

Update the Linux kernel to a version containing the fix for CVE-2025-37747. If immediate update is not possible, consider restricting access to the perf_event_open interface for unprivileged users.

Other vulnerabilities in Linux kernel

See all
Original NVD description (English source)

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) <IRQ> <IRQ> perf_event_overflow() perf_event_overflow() task_work_add(perf_pending_task) task_work_add(perf_pending_task) </IRQ> </IRQ> 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 assuming the event doesn't have any reference held and therefore can be freed right away must instead put the reference and let the reference counting to its job.

Vulnerability data from NVD (NIST) · CISA KEV · EPSS