Vulnerabilidad en kernel de Linux (CVE-2024-36894)

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: usb: gadget: f_fs: corrige la ejecución entre aio_cancel() y la solicitud AIO. Las aplicaciones basadas en FFS completas pueden utilizar la devolución de llamada aio_cancel() para quitar de la cola las solicitudes USB pendientes enviadas al UDC. Existe un escenario en el que la aplicación FFS emite una llamada de cancelación de AIO, mientras el UDC maneja una desconexión suave. Para una implementación basada en DWC3, la pila de llamadas se parece a la siguiente: Aplicación DWC3 Gadget FFS dwc3_gadget_soft_disconnect() ... --> dwc3_stop_active_transfers() --> dwc3_gadget_giveback(-ESHUTDOWN) --> ffs_epfile_async_io_complete() ffs_aio_cancel() --> usb_ep_free_request () --> usb_ep_dequeue() Actualmente no hay ningún bloqueo implementado entre el controlador de finalización de AIO y la cancelación de AIO, por lo que el problema ocurre si la rutina de finalización se ejecuta en paralelo a una llamada de cancelación de AIO proveniente de la aplicación FFS. A medida que la llamada de finalización libera la solicitud USB (io_data->req), la aplicación FFS también hace referencia a ella para la llamada usb_ep_dequeue(). Esto puede llevar a acceder a un puntero obsoleto/colgado. commit b566d38857fc ("usb: gadget: f_fs: use io_data->status consistentemente") reubicó usb_ep_free_request() en ffs_epfile_async_io_complete(). Sin embargo, para implementar correctamente el bloqueo para mitigar este problema, el spinlock no se puede agregar a ffs_epfile_async_io_complete(), ya que usb_ep_dequeue() (si se elimina con éxito una solicitud USB) llamará al controlador de finalización del controlador de función en el mismo contexto. De ahí que se llegue a un punto muerto. Solucione este problema moviendo usb_ep_free_request() de nuevo a ffs_user_copy_worker() y asegurándose de que establezca explícitamente io_data->req en NULL después de liberarlo dentro de ffs->eps_lock. Esto resuelve la condición de ejecución anterior, ya que la rutina ffs_aio_cancel() no continuará intentando sacar de la cola una solicitud que ya ha sido liberada, o ffs_user_copy_work() no liberará la solicitud USB hasta que la cancelación de AIO termine de hacer referencia a ella. Esta solución depende de el commit b566d38857fc ("usb: gadget: f_fs: use io_data->status consistentemente")