CVE-2021-47436

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: usb: musb: dsps: corrige la ruta del error de la sonda. El commit 7c75bde329d7 ("usb: musb: musb_dsps: request_irq() después de inicializar musb") ha invertido las llamadas a dsps_setup_optional_vbus_irq() y dsps_create_musb_pdev() sin actualizar correctamente la ruta del error. dsps_create_musb_pdev() asigna y registra un nuevo dispositivo de plataforma que debe cancelarse y liberarse con platform_device_unregister(), y esto falta en el error dsps_setup_optional_vbus_irq(). Mientras que en la rama maestra parece no desencadenar ningún problema, observé un bloqueo del kernel debido a una desreferencia del puntero NULL con un kernel estable v5.10.70 donde el parche mencionado anteriormente estaba respaldado. Con esta versión del kernel, se devuelve -EPROBE_DEFER la primera vez que se llama a dsps_setup_optional_vbus_irq(), lo que provoca que la sonda genere un error sin cancelar el registro del dispositivo de plataforma. Desafortunadamente, en el Beagle Bone Black Wireless, el dispositivo de plataforma que aún se encuentra en el sistema está siendo utilizado por el controlador del dispositivo USB Ethernet, lo que durante la fase de arranque provoca el bloqueo. Mi conocimiento limitado del mundo musb me impide revertir este compromiso que fue enviado para silenciar una advertencia de robot que, hasta donde tengo entendido, no tiene sentido. El objetivo de este parche era evitar que se activara una IRQ antes de que se registrara el dispositivo de la plataforma. Creo que esto nunca puede suceder debido al hecho de que habilitar las interrupciones se realiza mediante la devolución de llamada ->enable() del dispositivo musb de la plataforma, y este dispositivo de plataforma ya debe estar registrado para que el núcleo o cualquier otro usuario pueda usar esto. llamar de vuelta. Por lo tanto, decidí corregir la ruta del error, lo que podría evitar futuros errores en los núcleos principales y al mismo tiempo corregir los más antiguos.