CVE-2026-80659 in Linux
Resumen
por VulDB • 2026-08-28
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad:
mmc: vub300: diferir el reinicio hasta que cmd_mutex esté desbloqueado
vub300_cmndwork_thread() mantiene cmd_mutex mientras envía un comando y espera a la respuesta del mismo. Si la espera de la respuesta agota el tiempo, __vub300_command_response() cancela los URBs (USB Request Blocks) del comando y luego reinicia sincrónicamente el dispositivo USB mediante usb_reset_device().
Esa ruta de reinicio vuelve a entrar en el controlador a través de vub300_pre_reset(), que también toma cmd_mutex. Por lo tanto, el hilo de trabajo intenta adquirir recursivamente el mismo mutex mientras aún lo mantiene desde la ruta del comando.
Este problema fue encontrado por nuestra herramienta de análisis estático y luego revisado manualmente contra el árbol actual.
El PoC (Proof of Concept) funcional mantuvo al trabajador real y al portador de tiempo de espera/reinicio:
vub300_cmndwork_thread() __vub300_command_response() usb_lock_device_for_reset() usb_reset_device() vub300_pre_reset()
Lockdep reportó la adquisición recursiva del mismo hilo en cmd_mutex:
WARNING: posible detección de bloqueo recursivo ... (&test_vub300.cmd_mutex) ... en: usb_reset_device... [vuln_msv]
... (&test_vub300.cmd_mutex) ... en: vub300_cmndwork_thread+0x12/0x20 [vuln_msv]
Workqueue: vub300_cmd_wq vub300_cmndwork_thread [vuln_msv]
*** BLOQUEO MÚTUO (DEADLOCK) ***
Devuelva un indicador desde __vub300_command_response() cuando la ruta de tiempo de espera necesite reiniciar el dispositivo, y luego realice el reinicio después de que vub300_cmndwork_thread() haya limpiado el estado del comando en curso y liberado cmd_mutex. El reinicio sigue intentándose antes de mmc_request_done(), preservando el orden existente de finalización de solicitudes mientras se evita el bloqueo recursivo.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.