CVE-2023-52855

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: usb: dwc2: corrige posible desreferencia de puntero NULL causada por concurrencia de controladores. En _dwc2_hcd_urb_enqueue(), "urb->hcpriv = NULL" se ejecuta sin mantener presionado el bloqueo "hsotg->lock" . En _dwc2_hcd_urb_dequeue(): spin_lock_irqsave(&hsotg->lock, flags); ... if (!urb->hcpriv) { dev_dbg(hsotg->dev, "## urb->hcpriv es NULL ##
"); salir; } rc = dwc2_hcd_urb_dequeue(hsotg, urb->hcpriv); // Usa urb->hcpriv ... out: spin_unlock_irqrestore(&hsotg->lock, flags); Cuando _dwc2_hcd_urb_enqueue() y _dwc2_hcd_urb_dequeue() se ejecutan simultáneamente, la verificación NULL de "urb->hcpriv" se puede ejecutar antes de "urb->hcpriv = NULL". Después de que urb->hcpriv sea NULL, se puede usar en la llamada de función a dwc2_hcd_urb_dequeue(), lo que puede provocar una desreferencia del puntero NULL. Este posible error se encuentra mediante una herramienta experimental de análisis estático desarrollada por mí. Esta herramienta analiza las API de bloqueo para extraer pares de funciones que se pueden ejecutar simultáneamente y luego analiza las instrucciones en las funciones emparejadas para identificar posibles errores de concurrencia, incluidas ejecucións de datos y violaciones de atomicidad. El posible error anterior se informa cuando mi herramienta analiza el código fuente de Linux 6.5. Para corregir este posible error, se debe ejecutar "urb->hcpriv = NULL" manteniendo presionado el bloqueo "hsotg->lock". Después de usar este parche, mi herramienta nunca informa el posible error, con la configuración del kernel allyesconfig para x86_64. Como no tengo hardware asociado, no puedo probar el parche en tiempo de ejecución y simplemente verificarlo de acuerdo con la lógica del código.