Vulnerabilidad en kernel de Linux (CVE-2025-38016)
Fecha de publicación:
18/06/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: HID: bpf: abortar envío si dispositivo destruido La implementación actual de HID bpf asume que no pasará por ella ningún informe/solicitud de salida después de que se haya llamado a hid_bpf_destroy_device(). Esto lleva a un error que al desconectar ciertos tipos de dispositivos HID hace que se acceda a una SRCU limpiada. El error era anteriormente un fallo oculto hasta que un cambio reciente de x86 por CPU [1] hizo que accediera a páginas no presentes. El error se activará si se cumplen las siguientes condiciones: A) un dispositivo bajo el controlador tiene algunos LED encendidos B) hid_ll_driver->request() no está implementado (por ejemplo, logitech-djreceiver) Si se cumple la condición A, hidinput_led_worker() siempre se programa *después* de hid_bpf_destroy_device(). hid_destroy_device ` hid_bpf_destroy_device ` cleanup_srcu_struct(&hdev->bpf.srcu) ` hid_remove_device ` ... ` led_classdev_unregister ` led_trigger_set(led_cdev, NULL) ` led_set_brightness(led_cdev, LED_OFF) ` ... ` input_inject_event ` input_event_dispose ` hidinput_input_event ` schedule_work(&hid->led_work) [hidinput_led_worker] Esto funciona correctamente cuando no se cumple la condición B, en cuyo caso hidinput_led_worker() invoca hid_ll_driver->request(). Este es el caso de la mayoría de los controladores HID, que lo implementan o utilizan el genérico de usbhid. El propio controlador o uno subyacente abortará el procesamiento de la solicitud. De lo contrario, hidinput_led_worker() intenta hid_hw_output_report() y genera el error. hidinput_led_worker ` hid_hw_output_report ` dispatch_hid_bpf_output_report ` srcu_read_lock(&hdev->bpf.srcu) ` srcu_read_unlock(&hdev->bpf.srcu, idx) El error existe desde la introducción [2] de dispatch_hid_bpf_output_report(). Sin embargo, el mismo error también existe en dispatch_hid_bpf_raw_requests(), y he reproducido (sin efecto visible debido a la falta de [1], pero confirmado bpf.destroyed == 1) el error contra el commit (es decir, las correcciones:) que introduce la función. Esto se debe a que hidinput_led_worker() recurre a hid_hw_raw_request() cuando hid_ll_driver->output_report() no está implementado (p. ej., logitech- djreceiver). hidinput_led_worker ` hid_hw_output_report: -ENOSYS ` hid_hw_raw_request ` dispatch_hid_bpf_raw_requests ` srcu_read_lock(&hdev->bpf.srcu) ` srcu_read_unlock(&hdev->bpf.srcu, idx) Corrija el problema retornando antes en las dos funciones mencionadas si hid_bpf se marcó como destruido. Aunque dispatch_hid_bpf_device_event() maneja eventos de entrada y no hay evidencia de que pueda llamarse después de la destrucción, también se le agrega la misma verificación, como red de seguridad, para mantener la consistencia entre todas las funciones de despacho. El impacto del error en otras arquitecturas no está claro. Incluso si se trata de un fallo oculto, sigue siendo peligroso, ya que corrompe la dirección calculada por SRCU. Por lo tanto, se copia la lista estable. [1]: commit 9d7de2aa8b41 ("x86/percpu/64: Usar desplazamientos relativos por CPU") [2]: commit 9286675a2aed ("HID: bpf: añadir enlaces HID-BPF para hid_hw_output_report")
Gravedad: Pendiente de análisis
Última modificación:
18/06/2025
