Vulnerabilidad en kernel de Linux (CVE-2022-48760)

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: USB: core: corrige el bloqueo en usb_kill_urb agregando barreras de memoria el syzbot fuzzer ha identificado un error en el que los procesos se bloquean esperando que regrese usb_kill_urb(). Resulta que el problema no es desvincular la URB; eso funciona bien. Más bien, el problema surge cuando no se recibe la notificación de activación de que la URB ha completado. El motivo son los pedidos de acceso a la memoria en los sistemas SMP. En forma resumida, usb_kill_urb() y __usb_hcd_giveback_urb() operando simultáneamente en diferentes CPU realizan las siguientes acciones: CPU 0 CPU 1 ------------------------- --- --------------------------------- usb_kill_urb(): __usb_hcd_giveback_urb(): ... ... atomic_inc(&urb->rechazar); atomic_dec(&urb->use_count); ... ... wait_event(usb_kill_urb_queue, atomic_read(&urb->use_count) == 0); if (atomic_read(&urb->reject)) wake_up(&usb_kill_urb_queue); Limitando su atención a urb->reject y urb->use_count, puede ver que el patrón general de accesos en la CPU 0 es: escribir urb->reject, luego leer urb->use_count; mientras que el patrón general de accesos en la CPU 1 es: escribir urb->use_count, luego leer urb->reject. En los círculos de modelos de memoria se hace referencia a este patrón como SB (por "Store Buffering"), y es bien sabido que sin una aplicación adecuada del orden deseado de accesos (en forma de barreras de memoria) es completamente posible que una o ambas CPU para ejecutar sus lecturas antes de sus escrituras. El resultado final será que a veces la CPU 0 ve el antiguo valor no incrementado de urb->use_count mientras que la CPU 1 ve el antiguo valor no incrementado de urb->reject. En consecuencia, la CPU 0 termina en la cola de espera y nunca se activa, lo que provoca el bloqueo observado en usb_kill_urb(). El mismo patrón de accesos ocurre en usb_poison_urb() y la ruta de falla de usb_hcd_submit_urb(). El problema se soluciona agregando barreras de memoria adecuadas. Para proporcionar un orden adecuado de acceso a la memoria en el patrón SB, se requiere una barrera completa en ambas CPU. Los accesos atomic_inc() y atomic_dec() en sí no proporcionan ningún orden de memoria, pero como están presentes, podemos usar la barrera de memoria optimizada smp_mb__after_atomic() en las distintas rutinas para obtener el efecto deseado. Este parche agrega las barreras de memoria necesarias.