Linux kernel perf: closing a sigtrap event can hang the task freeing it

CVSS 5.5CVE-2025-37747Kernel, userspace & hypervisorcurated

Impact

If a deferred signal for a sigtrap perf event has not been delivered by the time the event file is closed, _free_event() waits in rcuwait_wait_event() for a task work item that task_work_cancel() can no longer remove, and the closing task hangs. Two processes each holding a perf event on the other can deadlock symmetrically. On a GPU node the practical cost is a wedged, unkillable process - profiling and tracing agents are common on these fleets, and a stuck task holding event references is cleared by rebooting, which means draining the node and losing whatever long training job was resident. Local denial of service only; the record shows no privilege escalation or disclosure.

Who can reach it

Local user able to call perf_event_open() for itself or a target pid. Nodes with perf_event_paranoid locked down to 3 or with perf unavailable to tenants have no unprivileged trigger; where profiling is allowed in tenant containers, any tenant process can reach it.

What to do

Update to a kernel carrying the fix (the linked stable commits reintroduce an event refcount taken when the perf task work is queued) and reboot the node. Interim mitigation is to raise perf_event_paranoid so unprivileged tenants cannot open perf events. No vendor advisory beyond the kernel commits in the record.

References

https://nvd.nist.gov/vuln/detail/CVE-2025-37747 https://git.kernel.org/stable/c/56799bc035658738f362acec3e7647bb84e68933 https://git.kernel.org/stable/c/aae58a39ac4c63c3fa53536fb2504c9f1d0e1719

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.