CVE-2026-74653

What the bug is

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.

Where it lives

The fix touches these files. If the subsystem is one you do not use, the practical exposure is lower, though the package is still the vulnerable one.

drivers/tty/serial/8250/8250_of.c

What this is

8250/16?50 (AND CLONE UARTS) SERIAL DRIVERMAINTAINERS section matched on drivers/tty/serial/8250* · linux-serial@vger.kernel.org · Maintained

Kernel module

8250_of

Check it on the machine

grep -wE 'CONFIG_SERIAL_8250|CONFIG_SERIAL_OF_PLATFORM' /boot/config-$(uname -r)

Reads the booted kernel's own configuration, on the machine and nowhere else. =y is built in, =m is a module, and an is not set line means the code is not there.

lsmod | grep -w 8250_of

Prints a line if that module is loaded right now, and nothing if it is not. One that is not loaded can still be loaded later by anything that needs it.

Show whether Debian builds this, per release

Debian builds this, but not on every flavour. At least one release below builds the code on some of its kernel flavours and not on others, so the answer depends on the architecture and flavour installed.

• bookwormBnot built on amd64/amd64, amd64/cloud-amd64, amd64/rt/amd64, i386/686-pae, i386/rt/686-pae
• trixieBnot built on amd64/amd64, amd64/cloud-amd64, amd64/rt/amd64, s390x/s390x
• forky, sidBnot built on amd64/amd64, amd64/cloud-amd64, amd64/rt-amd64, s390x/s390x
• bookworm · linux-6.12Bnot built on amd64/amd64, amd64/cloud-amd64, amd64/rt/amd64

B

built in on some, a module on others, absent on the rest

Build switches

CONFIG_SERIAL_8250, CONFIG_SERIAL_OF_PLATFORM

Reads as

all on means the file is compiled; any one off means it is not.

From the configuration Debian publishes for every kernel flavour it builds. It covers only the architectures Debian ships a linux-config package for, and nothing about a kernel you built yourself. Debian's own status above stays authoritative about the source package.MAINTAINERS kbuild Makefiles Debian linux-config packages

Signals

Published

2026-08-22 (2 months ago)source

CVSS

no vector published, unrated

Attack vector

not published

EPSS

0.17%, higher than 5.7% of all CVEssource

CISA KEV

not listedthe KEV catalogue

Debian urgency

not yet assignedsource

Subsystem

drivers/tty

Upstream fixes

The versions the CNA records as introducing and fixing this, and the commit for each. source

Introduced	Fixed in	Commit
2.6.36	6.12.106	c321dc5172c8
2.6.36	6.18.45	3ce24bc4d115
2.6.36	7.1.9	7795e8abedc8
2.6.36	7.2	142341547127

Debian advisories