{"id":"CVE-2026-74653","summary":"serial: 8250_of: clear stuck empty-FIFO RX-timeout on LPC32xx","details":"In the Linux kernel, the following vulnerability has been resolved:\n\nserial: 8250_of: clear stuck empty-FIFO RX-timeout on LPC32xx\n\nThe NXP LPC32xx UART (PORT_LPC3220) can latch an RX character-timeout\ninterrupt while the RX FIFO is empty: IIR reports UART_IIR_RX_TIMEOUT\n(0x0c) but LSR.DR is clear. A character timeout is only cleared by\nreading RHR, but serial8250_rx_chars() reads RHR only when LSR.DR is\nset, so nothing ever clears the condition. The interrupt is\nlevel-triggered and re-fires immediately, so on a single-core ARM926\nthe resulting interrupt storm livelocks the CPU.\n\nIt is reproducible when userspace repeatedly opens the front-panel port\n(ttyS1): serial8250_do_set_termios() re-enables interrupts on unlock and\nthe handler then spins forever with iir=0xcc lsr=0x60 ier=0x05, tripping\nthe soft-lockup detector in serial8250_handle_irq_locked().\n\nLPC32xx has no dedicated 8250 glue driver, it's driven by the generic\n8250_of. Add a hardware specific handle_irq for PORT_LPC3220, wired up\nin of_platform_serial_setup() the same way fsl8250_handle_irq is\ninstalled. The handler follows dw8250_handle_irq(): on an RX timeout\nwith an empty FIFO (LSR.DR and LSR.BI clear) it does one throwaway RHR\nread to clear the condition, then calls serial8250_handle_irq_locked().\nNo real received data is ever discarded, and it is a no-op on healthy\nUARTs which never report a timeout with DR clear.\n\nThis is the same class of bug already worked around in other 8250 drivers;\nsee commit 424d79183af0 (\"serial: 8250_dw: Avoid \"too much work\" from bogus rx timeout interrupt\")\nwhich reports the identical iir=0xcc/lsr=0x60. See also\nUART_RX_TIMEOUT_QUIRK in 8250_omap, and the note in 8250_bcm7271.","modified":"2026-08-28T03:47:15.221446710Z","published":"2026-08-22T15:32:28.521Z","database_specific":{"cna_assigner":"Linux","osv_generated_from":"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/74xxx/CVE-2026-74653.json"},"references":[{"type":"WEB","url":"https://git.kernel.org/stable/c/1423415471274abda87024967d7fe2206ceee0ea"},{"type":"WEB","url":"https://git.kernel.org/stable/c/3ce24bc4d115336218e59b7e286fd3a79f4fc4c6"},{"type":"WEB","url":"https://git.kernel.org/stable/c/7795e8abedc86438cae0454602cbf9038b94bf38"},{"type":"WEB","url":"https://git.kernel.org/stable/c/c321dc5172c8c66e21ffbeeb7a2ebb88ae6fd4c3"},{"type":"ADVISORY","url":"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/74xxx/CVE-2026-74653.json"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-74653"},{"type":"PACKAGE","url":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git"}],"affected":[{"ranges":[{"type":"GIT","repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","events":[{"introduced":"e6e912c4964ce5976e508881207dfa96d5f856d7"},{"fixed":"c321dc5172c8c66e21ffbeeb7a2ebb88ae6fd4c3"},{"fixed":"3ce24bc4d115336218e59b7e286fd3a79f4fc4c6"},{"fixed":"7795e8abedc86438cae0454602cbf9038b94bf38"},{"fixed":"1423415471274abda87024967d7fe2206ceee0ea"}]}],"database_specific":{"source":"https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2026-74653.json"}},{"package":{"name":"Kernel","ecosystem":"Linux"},"ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"2.6.36"},{"fixed":"6.12.106"}]},{"type":"ECOSYSTEM","events":[{"introduced":"6.13.0"},{"fixed":"6.18.45"}]},{"type":"ECOSYSTEM","events":[{"introduced":"6.19.0"},{"fixed":"7.1.9"}]}],"database_specific":{"source":"https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2026-74653.json"}}],"schema_version":"1.9.0"}