CVE-2026-89624 in Linux
Resumen
por VulDB • 2026-09-12
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad:
HID: universal-pidff: detener el dispositivo cuando falla la inicialización del force-feedback (retroalimentación háptica)
universal_pidff_probe() inicia el dispositivo con hid_hw_start() y luego, si falla la inicialización del force-feedback, devuelve el error a través de una etiqueta que solo ejecuta "return error". El dispositivo queda iniciado.
El núcleo HID no realiza las operaciones de limpieza (unwind) en nombre del controlador. __hid_device_probe() libera el grupo devres, cierra el informe y establece hdev->driver como NULL:
if (ret) {
devres_release_group(&hdev->dev, hdev->devres_group_id); hid_close_report(hdev); hdev->driver = NULL; }
El dispositivo de caracteres hidraw que hid_hw_start() registró a través de hid_connect() se asigna con kzalloc() y se añade con cdev_device_add(), por lo que no está gestionado por devres y sobrevive a esa liberación. Con hdev->driver en NULL, hid_device_remove() omite también la llamada a hid_hw_stop(), ya que solo realiza las operaciones de limpieza mientras el controlador sigue estando asociado. Por tanto, el registro persiste más allá del ciclo de vida del dispositivo en ambas rutas.
Al abrir el /dev/hidrawX superviviente se escribe en memoria liberada (freed memory). KASAN informa de una escritura use-after-free desde hidraw_open() -> hid_hw_open() -> la callback de apertura del transporte, que adquiere un spinlock dentro del objeto ya liberado. Basta con un descriptor que contenga una página de uso PID y sin informes de entrada: hidraw reclama el dispositivo para que hid_hw_start() tenga éxito, mientras que hid->inputs permanece vacío, lo que provoca que falle la inicialización del force-feedback. La otra vía de fallo devuelve en hid_pidff_init_with_quirks(): falta de informes de salida, error de asignación, pidff_init_fields(), pidff_check_autocenter(), recuento de efectos no utilizable, input_ff_create() - todos alcanzan la misma etiqueta.
Detener el dispositivo en esa ruta. Los controladores hid-dr.c y hid-emsff.c, que inician el dispositivo con la misma máscara HID_CONNECT_DEFAULT & ~HID_CONNECT_FF, ya realizan esta acción. Las dos etiquetas goto anteriores deben seguir devolviendo sin llamar a hid_hw_stop(), dado que ninguna de ellas tiene un dispositivo iniciado; por lo tanto, se debe proporcionar una etiqueta propia para la ruta que falla después del inicio.
Descubierto por XBOW, triado por Baul Lee <[email protected]>
If you want to get best quality of vulnerability data, you may have to visit VulDB.