CVE-2025-39737
Unknown Unknown - Not Provided
BaseFortify

Publication date: 2025-09-11

Last updated on: 2026-03-17

Assigner: kernel.org

Description
In the Linux kernel, the following vulnerability has been resolved: mm/kmemleak: avoid soft lockup in __kmemleak_do_cleanup() A soft lockup warning was observed on a relative small system x86-64 system with 16 GB of memory when running a debug kernel with kmemleak enabled. watchdog: BUG: soft lockup - CPU#8 stuck for 33s! [kworker/8:1:134] The test system was running a workload with hot unplug happening in parallel. Then kemleak decided to disable itself due to its inability to allocate more kmemleak objects. The debug kernel has its CONFIG_DEBUG_KMEMLEAK_MEM_POOL_SIZE set to 40,000. The soft lockup happened in kmemleak_do_cleanup() when the existing kmemleak objects were being removed and deleted one-by-one in a loop via a workqueue. In this particular case, there are at least 40,000 objects that need to be processed and given the slowness of a debug kernel and the fact that a raw_spinlock has to be acquired and released in __delete_object(), it could take a while to properly handle all these objects. As kmemleak has been disabled in this case, the object removal and deletion process can be further optimized as locking isn't really needed. However, it is probably not worth the effort to optimize for such an edge case that should rarely happen. So the simple solution is to call cond_resched() at periodic interval in the iteration loop to avoid soft lockup.
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2025-09-11
Last Modified
2026-03-17
Generated
2026-05-06
AI Q&A
2025-09-11
EPSS Evaluated
2026-05-05
NVD
CVE-2025-39737
Affected Vendors & Products
Showing 2 associated CPEs
Vendor Product Version / Range
linux linux_kernel 5.10.244
linux linux_kernel 6.1.153
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 involves a soft lockup in the Linux kernel's kmemleak feature during cleanup. When kmemleak tries to remove and delete a large number of memory leak objects (around 40,000) one-by-one in a loop, it can cause the CPU to become stuck for a long time (soft lockup) because of the slow processing and locking mechanisms. The fix involves periodically yielding the CPU during this cleanup loop to prevent the system from becoming unresponsive.


How can this vulnerability impact me? :

This vulnerability can cause a soft lockup, meaning the CPU can become stuck for an extended period during kmemleak cleanup, potentially leading to system unresponsiveness or degraded performance on systems running debug kernels with kmemleak enabled and large memory workloads.


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

This vulnerability can be detected by observing soft lockup warnings related to kmemleak in the system logs. Specifically, look for messages like 'watchdog: BUG: soft lockup - CPU#X stuck for XXs! [kworker/X:X:PID]' when running a debug kernel with kmemleak enabled. Monitoring kernel logs with commands such as 'dmesg | grep -i soft lockup' or 'journalctl -k | grep -i kmemleak' can help identify this issue.


What immediate steps should I take to mitigate this vulnerability?

To mitigate this vulnerability, ensure that the kernel includes the fix which calls cond_resched() periodically in the kmemleak cleanup loop to avoid soft lockups. If running a debug kernel with kmemleak enabled, consider adjusting the CONFIG_DEBUG_KMEMLEAK_MEM_POOL_SIZE to a lower value to reduce the number of kmemleak objects processed at once. Additionally, monitoring and managing workloads that involve hot unplug operations in parallel with kmemleak can help reduce the chance of triggering this issue.


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