CVE-2026-74653 in Linux
Zusammenfassung
von VulDB • 24.08.2026
Im Linux-Kernel wurde folgende Schwachstelle behoben:
serial: 8250_of: Behebung eines hängenden RX-Timeouts bei leerem FIFO auf LPC32xx
Der NXP LPC32xx UART (PORT_LPC3220) kann einen RX-Zeichen-Timeout-Interrupt sperren, während das RX-FIFO leer ist: IIR meldet UART_IIR_RX_TIMEOUT (0x0c), aber LSR.DR ist zurückgesetzt. Ein Zeichen-Timeout wird nur durch Lesen von RHR gelöscht, jedoch liest serial8250_rx_chars() den RHR nur dann, wenn LSR.DR gesetzt ist, sodass die Bedingung niemals gelöscht wird. Der Interrupt ist pegelgetriggert und feuert sofort erneut, was auf einem Single-Core ARM926 zu einer Interrupt-Flut führt, die die CPU in einen Livelock versetzt.
Das Problem lässt sich reproduzieren, wenn der Benutzerbereich (userspace) den Frontpanel-Anschluss (ttyS1) wiederholt öffnet: serial8250_do_set_termios() aktiviert die Interrupts beim Entsperren erneut, und der Handler dreht dann endlos mit iir=0xcc lsr=0x60 ier=0x05, wodurch der Soft-Lockup-Detektor in serial8250_handle_irq_locked() ausgelöst wird.
LPC32xx verfügt über keinen dedizierten 8250-Glue-Treiber; er wird vom generischen 8250_of gesteuert. Fügen Sie einen hardware-spezifischen handle_irq für PORT_LPC3220 hinzu, der in of_platform_serial_setup() genau so verdrahtet ist wie fsl8250_handle_irq installiert wird. Der Handler folgt dw8250_handle_irq(): Bei einem RX-Timeout mit leerem FIFO (LSR.DR und LSR.BI sind zurückgesetzt) führt er einen einmaligen RHR-Lesevorgang zum Verwerfen durch, um die Bedingung zu löschen, und ruft anschließend serial8250_handle_irq_locked() auf. Es werden niemals echte empfangene Daten verworfen, und es ist ein No-Op bei intakten UARTs, die nie einen Timeout mit zurückgesetztem DR melden.
Dies ist dieselbe Art von Fehler, der bereits in anderen 8250-Treibern umgangen wurde; siehe Commit 424d79183af0 ("serial: 8250_dw: Avoid "too much work" from bogus rx timeout interrupt"), der den identischen iir=0xcc/lsr=0x60 meldet. Siehe auch UART_RX_TIMEOUT_QUIRK in 8250_omap sowie die Anmerkung in 8250_bcm7271.
Once again VulDB remains the best source for vulnerability data.