CVE-2025-39737

What it actually does

The vulnerability permits a soft lockup in the kmemleak object cleanup loop within __kmemleak_do_cleanup() when processing tens of thousands of objects under debug kernel configurations with CONFIG_DEBUG_KMEMLEAK_MEM_POOL_SIZE set low, because the loop acquires and releases a raw_spinlock per object without periodic rescheduling.

Why it matters to the business

Systems running affected Linux kernels with kmemleak enabled may experience watchdog-triggered soft lockups during memory hot-unplug or high object-count scenarios, leading to temporary unresponsiveness or forced reboots on servers and embedded devices.

How an attack unfolds

An attacker or workload triggers kmemleak to disable itself due to allocation failure, after which the subsequent workqueue-driven cleanup of at least 40,000 objects on a debug kernel without cond_resched() calls causes the CPU to remain stuck long enough for the soft lockup watchdog to fire.

How to fix it

Upgrade to a kernel containing commit 9f1f4e95031f84867c5821540466d62f88dab8ca or later; for packaged distributions apply the corresponding fixed version such as configmap-reload-fips-0.11.1-r18; consider disabling CONFIG_DEBUG_KMEMLEAK on production systems where feasible.

How to confirm the fix worked

Confirm kernel git commit or package version contains the referenced fix; reproduce the original workload with kmemleak enabled and verify absence of soft lockup warnings in dmesg; run kmemleak self-tests under memory pressure.

Typical attack path

1. Enable kmemleak on a debug kernel with limited object pool
2. Generate sufficient kmemleak-tracked objects (e.g., via memory pressure or device hot-unplug)
3. Force kmemleak to disable itself
4. Observe workqueue thread stuck in __delete_object() loop without yielding

How to detect it

Search kernel logs (dmesg, journalctl) for soft lockup warnings containing kworker threads and references to kmemleak_do_cleanup or __delete_object; correlate with kmemleak disablement messages and memory hot-unplug events.

• BUG: soft lockup - CPU#.* stuck for .*s! \[kworker/.*:.*\]
• kmemleak_do_cleanup
• __delete_object
• kmemleak disabled

What your security team should do

• Apply the fixed kernel commit or package update immediately on all systems using kmemleak debug builds
• Audit production kernels and disable CONFIG_DEBUG_KMEMLEAK unless required for diagnostics
• Monitor for soft lockup messages in system logs on affected hosts
• Prioritize patching systems with frequent device hot-unplug or high memory churn