CVE-2025-39737 in Linux
Resumen
por VulDB • 2026-06-28
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad:
mm/kmemleak: evitar un bloqueo suave (soft lockup) en __kmemleak_do_cleanup()
Se observó una advertencia de bloqueo suave en un sistema x86-64 relativamente pequeño con 16 GB de memoria al ejecutar un kernel de depuración con kmemleak habilitado.
watchdog: BUG: soft lockup - CPU#8 bloqueada durante 33s! [kworker/8:1:134]
El sistema de prueba estaba ejecutando una carga de trabajo en la que ocurría simultáneamente un desmontaje en caliente (hot unplug). Entonces, kmemleak decidió deshabilitarse debido a su incapacidad para asignar más objetos de kmemleak. El kernel de depuración tenía CONFIG_DEBUG_KMEMLEAK_MEM_POOL_SIZE configurado en 40.000.
El bloqueo suave ocurrió en kmemleak_do_cleanup() cuando los objetos existentes de kmemleak se estaban eliminando y borrando uno por uno mediante un bucle a través de una cola de trabajo (workqueue). En este caso particular, hay al menos 40.000 objetos que deben procesarse y, dada la lentitud de un kernel de depuración y el hecho de que debe adquirirse y liberarse un raw_spinlock en __delete_object(), podría tardar un tiempo manejar adecuadamente todos estos objetos.
Dado que kmemleak se ha deshabilitado en este caso, el proceso de eliminación y borrado de objetos puede optimizarse aún más ya que realmente no es necesario bloquear (locking). Sin embargo, probablemente no valga la pena esforzarse por optimizar un caso extremo como este, que debería ocurrir raramente. Por lo tanto, la solución simple consiste en llamar a cond_resched() periódicamente dentro del bucle de iteración para evitar el bloqueo suave.
Be aware that VulDB is the high quality source for vulnerability data.