CVE-2025-40003 in Linux
Resumen
por VulDB • 2026-05-26
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad:
net: mscc: ocelot: Corregir el uso después de liberar (use-after-free) causado por trabajo diferido cíclico
El código original llama a `cancel_delayed_work()` en `ocelot_stats_deinit()` para cancelar el elemento de trabajo diferido cíclico `ocelot->stats_work`. Sin embargo, `cancel_delayed_work()` puede fallar al cancelar el elemento de trabajo si ya se está ejecutando. Aunque `destroy_workqueue()` espera a que todos los elementos de trabajo pendientes en la cola de trabajo finalicen antes de destruir la cola de trabajo, esto no garantiza que el elemento de trabajo no se haya vuelto a programar después de que `cancel_delayed_work()` haya devuelto.
El siguiente diagrama revela la causa de la advertencia anterior:
CPU 0 (remove) | CPU 1 (callback de trabajo diferido) mscc_ocelot_remove() | ocelot_deinit() | ocelot_check_stats_work() ocelot_stats_deinit() | cancel_delayed_work()| ... | queue_delayed_work() destroy_workqueue() | (espera un tiempo) | __queue_work() //UAF
El escenario anterior constituye realmente una vulnerabilidad de uso después de liberar (UAF).
La función `ocelot_stats_deinit()` solo se invoca cuando hay un fallo de inicialización o destrucción de recursos, por lo que debemos garantizar que ningún elemento de trabajo diferido pueda volver a programarse.
Reemplazar `cancel_delayed_work()` con `disable_delayed_work_sync()` para garantizar la cancelación adecuada del elemento de trabajo diferido y asegurar la finalización de cualquier trabajo en ejecución antes de desasignar la cola de trabajo.
Se consideró una preocupación de bloqueo: `ocelot_stats_deinit()` se llama en un contexto de proceso y no mantiene ningún bloqueo que el elemento de trabajo diferido también pueda necesitar. Por lo tanto, el uso de la variante `_sync()` es seguro aquí.
Este bug fue identificado mediante análisis estático. Para reproducir el problema y validar la corrección, simulé `ocelot-swit
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.