CVE-2025-39953 Affecting libperf package, versions *
Threat Intelligence
The probability is the direct output of the EPSS model, and conveys an overall sense of the threat of exploitation in the wild. The percentile measures the EPSS probability relative to all known EPSS scores. Note: This data is updated daily, relying on the latest available EPSS model version. Check out the EPSS documentation for more details.
Do your applications use this vulnerable package?
In a few clicks we can analyze your entire application and see what components are vulnerable in your application, and suggest you quick fixes.
Test your applications- Snyk IDSNYK-CENTOS9-LIBPERF-13394640
- published7 Oct 2025
- disclosed4 Oct 2025
Introduced: 4 Oct 2025
NewCVE-2025-39953 (opens in a new tab)How to fix?
There is no fixed version for Centos:9 libperf.
NVD Description
Note: Versions mentioned in the description apply only to the upstream libperf package and not the libperf package as distributed by Centos.
See How to fix? for Centos:9 relevant fixed versions and status.
In the Linux kernel, the following vulnerability has been resolved:
cgroup: split cgroup_destroy_wq into 3 workqueues
A hung task can occur during [1] LTP cgroup testing when repeatedly mounting/unmounting perf_event and net_prio controllers with systemd.unified_cgroup_hierarchy=1. The hang manifests in cgroup_lock_and_drain_offline() during root destruction.
Related case: cgroup_fj_function_perf_event cgroup_fj_function.sh perf_event cgroup_fj_function_net_prio cgroup_fj_function.sh net_prio
Call Trace: cgroup_lock_and_drain_offline+0x14c/0x1e8 cgroup_destroy_root+0x3c/0x2c0 css_free_rwork_fn+0x248/0x338 process_one_work+0x16c/0x3b8 worker_thread+0x22c/0x3b0 kthread+0xec/0x100 ret_from_fork+0x10/0x20
Root Cause:
CPU0 CPU1 mount perf_event umount net_prio cgroup1_get_tree cgroup_kill_sb rebind_subsystems // root destruction enqueues // cgroup_destroy_wq // kill all perf_event css // one perf_event css A is dying // css A offline enqueues cgroup_destroy_wq // root destruction will be executed first css_free_rwork_fn cgroup_destroy_root cgroup_lock_and_drain_offline // some perf descendants are dying // cgroup_destroy_wq max_active = 1 // waiting for css A to die
Problem scenario:
- CPU0 mounts perf_event (rebind_subsystems)
- CPU1 unmounts net_prio (cgroup_kill_sb), queuing root destruction work
- A dying perf_event CSS gets queued for offline after root destruction
- Root destruction waits for offline completion, but offline work is blocked behind root destruction in cgroup_destroy_wq (max_active=1)
Solution: Split cgroup_destroy_wq into three dedicated workqueues: cgroup_offline_wq – Handles CSS offline operations cgroup_release_wq – Manages resource release cgroup_free_wq – Performs final memory deallocation
This separation eliminates blocking in the CSS free path while waiting for offline operations to complete.
[1] https://github.com/linux-test-project/ltp/blob/master/runtest/controllers
References
- https://access.redhat.com/security/cve/CVE-2025-39953
- https://git.kernel.org/stable/c/05e0b03447cf215ec384210441b34b7a3b16e8b0
- https://git.kernel.org/stable/c/4a1e3ec28e8062cd9f339aa6a942df9c5bcb6811
- https://git.kernel.org/stable/c/79f919a89c9d06816dbdbbd168fa41d27411a7f9
- https://git.kernel.org/stable/c/993049c9b1355c78918344a6403427d53f9ee700
- https://git.kernel.org/stable/c/a0c896bda7077aa5005473e2c5b3c27173313b4c
- https://git.kernel.org/stable/c/cabadd7fd15f97090f752fd22dd7f876a0dc3dc4
- https://git.kernel.org/stable/c/ded4d207a3209a834b6831ceec7f39b934c74802
- https://git.kernel.org/stable/c/f2795d1b92506e3adf52a298f7181032a1525e04