CVE-2026-74653

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> serial: 8250_of: clear stuck empty-FIFO RX-timeout on LPC32xx<br /> <br /> The NXP LPC32xx UART (PORT_LPC3220) can latch an RX character-timeout<br /> interrupt while the RX FIFO is empty: IIR reports UART_IIR_RX_TIMEOUT<br /> (0x0c) but LSR.DR is clear. A character timeout is only cleared by<br /> reading RHR, but serial8250_rx_chars() reads RHR only when LSR.DR is<br /> set, so nothing ever clears the condition. The interrupt is<br /> level-triggered and re-fires immediately, so on a single-core ARM926<br /> the resulting interrupt storm livelocks the CPU.<br /> <br /> It is reproducible when userspace repeatedly opens the front-panel port<br /> (ttyS1): serial8250_do_set_termios() re-enables interrupts on unlock and<br /> the handler then spins forever with iir=0xcc lsr=0x60 ier=0x05, tripping<br /> the soft-lockup detector in serial8250_handle_irq_locked().<br /> <br /> LPC32xx has no dedicated 8250 glue driver, it&amp;#39;s driven by the generic<br /> 8250_of. Add a hardware specific handle_irq for PORT_LPC3220, wired up<br /> in of_platform_serial_setup() the same way fsl8250_handle_irq is<br /> installed. The handler follows dw8250_handle_irq(): on an RX timeout<br /> with an empty FIFO (LSR.DR and LSR.BI clear) it does one throwaway RHR<br /> read to clear the condition, then calls serial8250_handle_irq_locked().<br /> No real received data is ever discarded, and it is a no-op on healthy<br /> UARTs which never report a timeout with DR clear.<br /> <br /> This is the same class of bug already worked around in other 8250 drivers;<br /> see commit 424d79183af0 ("serial: 8250_dw: Avoid "too much work" from bogus rx timeout interrupt")<br /> which reports the identical iir=0xcc/lsr=0x60. See also<br /> UART_RX_TIMEOUT_QUIRK in 8250_omap, and the note in 8250_bcm7271.