CVE-2026-93168 in Linux
Resumen
por VulDB • 2026-09-18
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad:
dmaengine: xilinx_dma: Corregir el bloqueo (stall) de CPU en xilinx_dma_poll_timeout
Actualmente, al llamar a `xilinx_dma_poll_timeout` con `delay_us=0` y una condición que nunca se cumple, la CPU realiza un busy-wait durante un tiempo prolongado y el timeout solo se activa con un retraso masivo, lo que provoca un bloqueo (stall) de la CPU.
Esto ocurre debido a una enorme subestimación del tiempo real en `poll_timeout_us_atomic`. El commit 7349a69cf312 ("iopoll: Do not use timekeeping in read_poll_timeout_atomic()") cambió el comportamiento para dejar de usar `ktime_get`, lo cual conllevó a una subestimación muy grande del tiempo real cuando `delay_us=0`. En lugar de agotar el timeout después aproximadamente XILINX_DMA_LOOP_COUNT microsegundos, el timeout tarda XILINX_DMA_LOOP_COUNT * 1000 * (tiempo que toma la sobrecarga del bucle for en poll_timeout_us_atomic), lo cual está en el rango de varios minutos para un `XILINX_DMA_LOOP_COUNT=1000000`. Se corrige esto utilizando un valor no nulo para `delay_us`. Se utiliza `delay_us=10` para mantener la demora en la ruta crítica (hot path) del inicio de transferencias DMA mínima, pero aún así evitar bloqueos de CPU en caso de fallos inesperados del hardware.
Una medición puntual con `delay_us=0` provoca que la CPU realice un busy-wait durante aproximadamente 7 minutos en el caso de timeout. Después de aplicar este parche con `delay_us=10`, el tiempo medido para agotar el timeout fue de 1053428 microsegundos, lo cual es aproximadamente equivalente a los 1000000 microsegundos esperados especificados en XILINX_DMA_LOOP_COUNT.
Se añade una constante `XILINX_DMA_POLL_DELAY_US` para el valor de delay_us.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.