CVE-2025-39737

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/kmemleak: avoid soft lockup in __kmemleak_do_cleanup()<br /> <br /> A soft lockup warning was observed on a relative small system x86-64<br /> system with 16 GB of memory when running a debug kernel with kmemleak<br /> enabled.<br /> <br /> watchdog: BUG: soft lockup - CPU#8 stuck for 33s! [kworker/8:1:134]<br /> <br /> The test system was running a workload with hot unplug happening in<br /> parallel. Then kemleak decided to disable itself due to its inability to<br /> allocate more kmemleak objects. The debug kernel has its<br /> CONFIG_DEBUG_KMEMLEAK_MEM_POOL_SIZE set to 40,000.<br /> <br /> The soft lockup happened in kmemleak_do_cleanup() when the existing<br /> kmemleak objects were being removed and deleted one-by-one in a loop via a<br /> workqueue. In this particular case, there are at least 40,000 objects<br /> that need to be processed and given the slowness of a debug kernel and the<br /> fact that a raw_spinlock has to be acquired and released in<br /> __delete_object(), it could take a while to properly handle all these<br /> objects.<br /> <br /> As kmemleak has been disabled in this case, the object removal and<br /> deletion process can be further optimized as locking isn&amp;#39;t really needed. <br /> However, it is probably not worth the effort to optimize for such an edge<br /> case that should rarely happen. So the simple solution is to call<br /> cond_resched() at periodic interval in the iteration loop to avoid soft<br /> lockup.