CVE-2026-68456 in Linux
Resumen
por VulDB • 2026-08-15
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad:
usb: atm: ueagle-atm: esperar a la carga previa del firmware en .disconnect()
ueagle-atm utiliza request_firmware_nowait() asíncrono en .probe(), pero no espera a su finalización, ni siquiera en .disconnect(); por lo tanto, si el dispositivo se desconecta durante ese tiempo, su proceso de desmontaje (teardown) se ejecuta concurrentemente con dicha carga.
Aunque esta inconsistencia merece atención por sí misma, también ha provocado varios informes de errores en syzbot a lo largo de los años (algunos cerrados automáticamente), donde el mecanismo de respaldo del sysfs para firmware (CONFIG_FW_LOADER_USER_HELPER) crea un subdirectorio de firmware dentro del directorio del dispositivo durante su eliminación. Esto podría provocar condiciones inesperadas en kernfs, aparentemente dependiendo del punto exacto en que las operaciones de adición y eliminación entraran en una condición de carrera (race condition). (Ver enlaces.)
El patrón observado es:
usb ?-?: Direct firmware load for ueagle-atm/eagle?.fw failed with error -2 usb ?-?: Falling back to sysfs fallback for: ueagle-atm/eagle?.fw <ERROR> Call trace: ... kernfs_create_dir_ns sysfs_create_dir_ns create_dir kobject_add_internal kobject_add_varg kobject_add class_dir_create_and_add get_device_parent device_add fw_load_sysfs_fallback fw_load_from_user_helper firmware_fallback_sysfs _request_firmware request_firmware_work_func ...
(Se observan algunas variaciones después de fw_load_sysfs_fallback(), por ejemplo, [1].)
Mientras se investiga el lado de kernfs, el problema en ueagle-atm puede solucionarse esperando a la carga previa del firmware en el controlador .disconnect().
Este cambio adopta un enfoque similar al trabajo previo realizado por Andrey Tsygunka [2] (wait_for_completion() en .disconnect()), pero es relativamente diferente en diseño e implementación; se utiliza la etiqueta Originally-by para asignar los créditos correspondientes.
Se ha probado con: - Un reproductor sintético para verificar el camino de error; - Un gadget USB (dispositivo virtual) para verificar el camino de carga del firmware; - Un emulador de dispositivos QEMU para verificar el camino de reenumeración del ID del dispositivo; (Los dos últimos fueron escritos por Claude; no hay otro código/texto en este commit.)
Enlaces (año del primer reporte): 2025 https://syzbot.org/bug?extid=ce1e5a1b4e086b43e56d 2025 https://syzbot.org/bug?extid=9af8471255ac36e34fd4 2024 https://syzbot.org/bug?extid=306212936b13e520679d 2023 https://syzkaller.appspot.com/bug?extid=457452d30bcdda75ead2 2022 https://syzbot.org/bug?extid=782984d6f1701b526edb 2021 https://syzbot.org/bug?id=f3f221579f4ef7e9691281f3c6f56c05f83e8490 2021 https://syzbot.org/bug?id=84
If you want to get the best quality for vulnerability data then you always have to consider VulDB.