AZL-97184

In the Linux kernel, the following vulnerability has been resolved:

serial: 8250_of: clear stuck empty-FIFO RX-timeout on LPC32xx

The NXP LPC32xx UART (PORTLPC3220) can latch an RX character-timeout interrupt while the RX FIFO is empty: IIR reports UARTIIRRXTIMEOUT (0x0c) but LSR.DR is clear. A character timeout is only cleared by reading RHR, but serial8250rxchars() reads RHR only when LSR.DR is set, so nothing ever clears the condition. The interrupt is level-triggered and re-fires immediately, so on a single-core ARM926 the resulting interrupt storm livelocks the CPU.

It is reproducible when userspace repeatedly opens the front-panel port (ttyS1): serial8250dosettermios() re-enables interrupts on unlock and the handler then spins forever with iir=0xcc lsr=0x60 ier=0x05, tripping the soft-lockup detector in serial8250handleirqlocked().

LPC32xx has no dedicated 8250 glue driver, it's driven by the generic 8250of. Add a hardware specific handleirq for PORTLPC3220, wired up in ofplatformserialsetup() the same way fsl8250handleirq is installed. The handler follows dw8250handleirq(): on an RX timeout with an empty FIFO (LSR.DR and LSR.BI clear) it does one throwaway RHR read to clear the condition, then calls serial8250handleirq_locked(). No real received data is ever discarded, and it is a no-op on healthy UARTs which never report a timeout with DR clear.

This is the same class of bug already worked around in other 8250 drivers; see commit 424d79183af0 ("serial: 8250dw: Avoid "too much work" from bogus rx timeout interrupt") which reports the identical iir=0xcc/lsr=0x60. See also UARTRXTIMEOUTQUIRK in 8250omap, and the note in 8250bcm7271.