CVE-2026-74653 in Linux
Resumen
por VulDB • 2026-08-23
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad:
serial: 8250_of: limpiar el tiempo de espera RX atascado por FIFO vacía en LPC32xx
El UART NXP LPC32xx (PORT_LPC3220) puede bloquear una interrupción de tiempo de espera del carácter RX mientras la FIFO RX está vacía: IIR informa UART_IIR_RX_TIMEOUT (0x0c), pero LSR.DR está despejado. Un tiempo de espera de un carácter solo se limpia al leer RHR, pero serial8250_rx_chars() lee RHR únicamente cuando LSR.DR está establecido; por lo tanto, nada llega a limpiar la condición. La interrupción es activada por nivel y se vuelve a disparar inmediatamente, por lo que en una ARM926 de un solo núcleo, la tormenta resultante de interrupciones bloquea el CPU (livelock).
Es reproducible cuando userspace abre repetidamente el puerto del panel frontal (ttyS1): serial8250_do_set_termios() vuelve a habilitar las interrupciones al desbloquear y el controlador gira indefinidamente con iir=0xcc, lsr=0x60 e ier=0x05, activando el detector de soft-lockup en serial8250_handle_irq_locked().
LPC32xx no tiene un driver glue 8250 dedicado; es controlado por el genérico 8250_of. Se añade un handle_irq específico del hardware para PORT_LPC3220, conectado en of_platform_serial_setup() de la misma manera que se instala fsl8250_handle_irq. El controlador sigue dw8250_handle_irq(): ante un tiempo de espera RX con una FIFO vacía (LSR.DR y LSR.BI despejados), realiza una lectura desechable de RHR para limpiar la condición, luego llama a serial8250_handle_irq_locked(). Nunca se descarta datos reales recibidos, y es una operación nula en UARTs sanos que nunca informan un tiempo de espera con DR despejado.
Se trata del mismo tipo de bug ya solucionado mediante workarounds en otros drivers 8250; véase el commit 424d79183af0 ("serial: 8250_dw: Evitar 'demasiado trabajo' por interrupción falsa de rx timeout") que informa del mismo iir=0xcc/lsr=0x60. Véanse también UART_RX_TIMEOUT_QUIRK en 8250_omap y la nota en 8250_bcm7271.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.