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

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: Bluetooth: btnxpuart: resolver error de tiempo de espera de TX en la prueba de esfuerzo de ahorro de energía Esto corrige el problema de tiempo de espera de TX observado al ejecutar una prueba de esfuerzo en btnxpuart durante un par de horas, de modo que el intervalo entre dos comandos HCI coincida con el valor de tiempo de espera de ahorro de energía de 2 segundos. Procedimiento de prueba usando script bash: hciconfig hci0 up //Habilitar función de ahorro de energía hcitool -i hci0 cmd 3f 23 02 00 00 while (true) do hciconfig hci0 leadv sleep 2 hciconfig hci0 noleadv sleep 2 done Registro de errores, después de agregar algunas impresiones de depuración más: Bluetooth: btnxpuart_queue_skb(): 01 0A 20 01 00 Bluetooth: hci0: Establecer UART break: activado, estado=0 Bluetooth: hci0: btnxpuart_tx_wakeup() tx_work programado Bluetooth: hci0: btnxpuart_tx_work() dequeue: 01 0A 20 01 00 No se puede establecer el modo de anuncio en hci0: Se agotó el tiempo de conexión (110) Bluetooth: hci0: comando 0x200a Tiempo de espera de TX: Cuando el mecanismo de ahorro de energía activa la interrupción de UART y btnxpuart_tx_work() se programa simultáneamente, psdata->ps_state se lee como PS_STATE_AWAKE, lo que impide que se programe psdata->work, que es responsable de desactivar la interrupción de UART. Este problema se soluciona añadiendo un mutex ps_lock alrededor de la activación/desactivación de la interrupción de UART, así como alrededor de la lectura/escritura de ps_state. btnxpuart_tx_wakeup() ahora leerá el valor actualizado de ps_state. Si ps_state es PS_STATE_SLEEP, primero programará psdata->work y luego se reprogramará a sí mismo una vez que la interrupción de UART se haya desactivado y ps_state sea PS_STATE_AWAKE. Probé el script anterior durante 50,000 iteraciones y el error de tiempo de espera de TX ya no se observó.