CVE-2025-39953
Unknown Unknown - Not Provided
BaseFortify

Publication date: 2025-10-04

Last updated on: 2025-10-06

Assigner: kernel.org

Description
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: 1. CPU0 mounts perf_event (rebind_subsystems) 2. CPU1 unmounts net_prio (cgroup_kill_sb), queuing root destruction work 3. A dying perf_event CSS gets queued for offline after root destruction 4. 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
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2025-10-04
Last Modified
2025-10-06
Generated
2026-05-07
AI Q&A
2025-10-04
EPSS Evaluated
2026-05-05
NVD
Affected Vendors & Products
Showing 1 associated CPE
Vendor Product Version / Range
linux kernel *
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-UNKNOWN
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?

This vulnerability in the Linux kernel involves a hang (deadlock) that occurs during cgroup testing when repeatedly mounting and unmounting perf_event and net_prio controllers with systemd.unified_cgroup_hierarchy=1. The hang happens in the function cgroup_lock_and_drain_offline() during root cgroup destruction because the root destruction work and offline work are queued on the same workqueue (cgroup_destroy_wq) with max_active=1, causing a circular wait. The root destruction waits for offline completion, but offline work is blocked behind root destruction, leading to a hung task. The fix splits the single workqueue into three dedicated workqueues to avoid this blocking.


How can this vulnerability impact me? :

This vulnerability can cause a hung task in the Linux kernel when certain cgroup controllers are repeatedly mounted and unmounted, potentially leading to system instability or unresponsiveness during these operations. This could affect system performance or availability, especially in environments relying on cgroup resource management.


How can this vulnerability be detected on my network or system? Can you suggest some commands?

This vulnerability manifests as a hung task during repeated mounting and unmounting of perf_event and net_prio controllers with systemd.unified_cgroup_hierarchy=1, specifically hanging in cgroup_lock_and_drain_offline() during root destruction. Detection can be done by running the Linux Test Project (LTP) cgroup tests that involve mounting/unmounting perf_event and net_prio controllers, such as the cgroup_fj_function_perf_event and cgroup_fj_function_net_prio tests. Monitoring for hung tasks or kernel workqueue stalls related to cgroup_destroy_wq can indicate the issue. Specific commands include running LTP tests from https://github.com/linux-test-project/ltp/blob/master/runtest/controllers and checking kernel logs for call traces involving cgroup_lock_and_drain_offline.


What immediate steps should I take to mitigate this vulnerability?

The vulnerability is mitigated by applying the patch that splits the cgroup_destroy_wq workqueue into three dedicated workqueues: cgroup_offline_wq, cgroup_release_wq, and cgroup_free_wq. This eliminates blocking in the CSS free path. Immediate mitigation steps include updating the Linux kernel to a version that includes this fix. Additionally, avoiding repeated mounting and unmounting of perf_event and net_prio controllers with systemd.unified_cgroup_hierarchy=1 until the patch is applied can reduce the risk of encountering the hang.


Ask Our AI Assistant
Need more information? Ask your question to get an AI reply (Powered by our expertise)
0/70
EPSS Chart