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

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: xhci: Manejar el borrado de TD para el caso de múltiples flujos Cuando se utilizan múltiples flujos, es posible que haya múltiples TD en vuelo cuando se detiene un endpoint. Necesitamos emitir un puntero de salida de cola TR para cada uno, para garantizar que todo se restablezca correctamente y se borren los cachés. Cambie la lógica para que cualquier N>1 TD que se encuentre activo para diferentes flujos se difiera hasta después de que se procese el primero, llamando a xhci_invalidate_cancelled_tds() nuevamente desde xhci_handle_cmd_set_deq() para poner en cola otro comando hasta que hayamos terminado con todos ellos. También cambie las rutas de error/"nunca debería suceder" para asegurarnos de que al menos borramos los TD afectados, incluso si no podemos emitir un comando para borrar el caché del hardware, y quejarnos en voz alta con un xhci_warn() si esto alguna vez sucede. Este caso de problema se remonta al commit e9df17eb1408 ("USB: xhci: Suposiciones correctas sobre el número de anillos por endpoint.") al principio de la vida del controlador XHCI, cuando se agregó por primera vez el soporte de transmisión. Luego se identificó, pero no se solucionó ni se convirtió en una advertencia en el commit 674f8438c121 ("xhci: dividir el manejo de endpoints detenidos en dos pasos"), que agregó un comentario FIXME para el caso del problema (sin cambiar materialmente el comportamiento, hasta donde yo sé). , aunque la nueva lógica hizo que el problema fuera más obvio). Luego, más tarde, en el commit 94f339147fc3 ("xhci: Se corrigió el error al devolver algunas URB canceladas en caché"), se reconoció nuevamente. [Mathias: commit 94f339147fc3 ("xhci: Se corrigió el error al devolver algunas URB canceladas en caché") fue una solución de regresión específica para el parche mencionado anteriormente. Los usuarios informaron problemas con el USB atascado después de desmontar/desconectar dispositivos UAS. Esto revirtió la limpieza de TD de múltiples transmisiones a su estado original.] Aparentemente, el autor de el commit estaba al tanto del problema (pero aún así decidió enviarlo): todavía se mencionaba como FIXME, se agregó un xhci_dbg() para registrar el condición del problema y el problema restante se mencionó en la descripción de El commit. La elección de crear el tipo de registro xhci_dbg() para lo que, en este momento, es una condición rota completamente no controlada y conocida es desconcertante y desafortunada, ya que garantiza que ningún usuario real verá el registro en producción, lo que lo hace casi no depurable ( de hecho, incluso si activa DEBUG, el mensaje realmente no indica que haya ningún problema). Me tomó *meses* de fallas aleatorias de xHC para finalmente encontrar una reproducción confiable y poder realizar una sesión de depuración profunda, que podría haberse evitado si esta condición rota y no controlada se hubiera informado con una advertencia, como debería haber sido. ha sido un error que se dejó intencionalmente sin corregir (sin importar que no debería haberse dejado en absoluto). > Se necesita otra solución para solucionar el borrado de los cachés de todos los anillos de transmisión con > TD cancelados, pero no es tan urgente. 3 años después de esa declaración y 14 años después de que se introdujo el error original, creo que finalmente es hora de solucionarlo. Y tal vez la próxima vez no dejemos errores sin corregir (que en realidad son peores que el error original), y hagamos que la gente revise las confirmaciones del kernel, por favor. Soluciona fallas de xHC y fallas de IOMMU con dispositivos UAS al manejar errores/fallas. La reproducción más sencilla es usar `hdparm` para marcar un sector inicial (por ejemplo, 1024) en un disco como defectuoso, luego `cat /dev/sdX > /dev/null` en un bucle. ---truncado---