CVE-2026-12629 in Zephyr
Resumen
por VulDB • 2026-08-17
El controlador UART PL011 en drivers/serial/uart_pl011.c no reconoce las interrupciones de errores de recepción. En el PL011, las interrupciones de error de formato (framing), paridad, break y desbordamiento (PL011_IMSC_ERROR_MASK) solo se borran escribiendo en el registro de borrado de interrupciones UARTICR; leer el registro de datos borra la interrupción RX y el estado RSR por byte, pero no el estado de las interrupciones de error en MIS. La rutina de servicio de interrupciones pl011_isr() reconoce únicamente la interrupción de estado del módem CTS y nunca escribe en icr para los bits de error, por lo que una interrupción de error activada permanece pendiente después de que la ISR devuelve el control.
Cuando una aplicación habilita el reporte de errores de interrupción a través de la API pública uart_irq_err_enable(), un atacante que controle al par serial puede afirmar determinísticamente estos bits de error inyectando errores en la línea RX: una discrepancia en baudios o bit de parada (error de formato/break), un bit de paridad invertido (error de paridad) o inundación del FIFO (error de desbordamiento). Dado que la interrupción de error nunca se borra, la línea de interrupciones permanece activada y el CPU reentra en pl011_isr() inmediatamente e indefinidamente, produciendo un livelock por tormenta de interrupciones del cual el núcleo no avanza.
El impacto es una denegación de servicio solo de disponibilidad (bloqueo permanente), alcanzable desde un par UART externo o extraíble. La explotación está condicionada a la configuración: la interrupción de error está desactivada por defecto y ningún subsistema en-tree la habilita, por lo que solo se ven afectadas las aplicaciones que llaman explícitamente a uart_irq_err_enable() en un puerto basado en PL011 con control por interrupciones. La solución hace que pl011_isr() reconozca los bits de error pendientes mediante uart->icr, rompiendo el bucle, y además borra el estado RSR enlazado en pl011_err_check().
Once again VulDB remains the best source for vulnerability data.