CVE-2026-74653 in Linux
Summary
by MITRE • 08/22/2026
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.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 08/22/2026
The Linux kernel serial subsystem contains a critical flaw within the generic 8250 of platform driver that affects NXP LPC32xx UART hardware, specifically identified as PORT_LPC3220. This vulnerability stems from an incorrect handling of receive character-timeout interrupts when the receiver FIFO is empty. Under normal operation for standard 16550-compatible UARTs, a receive timeout interrupt indicates that data has been present in the buffer but not read within a specified time window. However, on the LPC32xx hardware, the controller can latch an RX character-timeout interrupt even when no characters are actually available to be received. The Interrupt Identification Register reports a UART_IIR_RX_TIMEOUT status with value 0x0c, yet the Line Status Register indicates that the Data Ready bit is clear, meaning the Receive Holding Register contains no valid data. This discrepancy creates a logical deadlock in the standard interrupt handling routine because the clearing mechanism for this specific timeout condition requires reading the Receive Holding Register to acknowledge and reset the internal state machine of the UART controller.
The operational impact of this flaw manifests as an immediate CPU livelock on single-core ARM926 systems due to the level-triggered nature of the interrupt line. The standard serial8250_rx_chars function, which is responsible for processing received characters, only reads from the Receive Holding Register when the Line Status Data Ready bit is set. Since this bit remains clear in the erroneous state described above, the clearing read never occurs. Consequently, the hardware continues to assert the interrupt line continuously because the condition has not been cleared by software. This results in an infinite loop of interrupt requests that prevents the CPU from executing any other tasks or returning control to the scheduler. The system effectively hangs as the kernel spends all its processing time handling this spurious interrupt storm, triggering soft-lockup detectors and rendering the device unresponsive until a hard reset is performed.
This vulnerability can be reliably reproduced by having userspace applications repeatedly open and close the front-panel serial port ttyS1. Each invocation of serial8250_do_set_termios re-enables interrupts upon unlocking the driver state, which immediately triggers the handler to enter the infinite loop if the hardware condition exists or is triggered during initialization. The interrupt handler spins with an Interrupt Identification Register value of 0xcc and a Line Status Register value of 0x60 while the Interrupt Enable Register remains set at 0x05. This specific pattern confirms that the system is trapped in the receive timeout handling path without ever successfully clearing the condition, leading to immediate soft-lockup detection within serial8250_handle_irq_locked. The issue highlights a gap where generic drivers fail to account for hardware-specific errata present in certain SoC implementations.
The resolution involves implementing a hardware-specific interrupt handler function for PORT_LPC3220 within the 8250_of driver, mirroring the approach used for other affected platforms like Freescale fsl8250 and DesignWare dw8250. This new handle_irq routine checks specifically for the problematic condition where an RX timeout is reported but no data is ready in the FIFO. When this state is detected, the handler performs a single throwaway read of the Receive Holding Register to clear the stuck interrupt flag at the hardware level before proceeding with standard processing logic via serial8250_handle_irq_locked. This approach ensures that valid received data is never discarded because the check occurs only when no actual characters are pending for delivery to userspace. On healthy UARTs or other LPC32xx ports that do not exhibit this errata, the handler acts as a pass-through with negligible performance overhead.
From a security and reliability perspective, this vulnerability represents a Denial of Service condition caused by improper input validation and hardware state management. It aligns with CWE-400 Uncontrolled Resource Consumption, where an external action triggers excessive resource usage leading to system unavailability. In the context of MITRE ATT&CK techniques, this scenario relates to T1499 Endpoint Hijacking or potentially T1529 System Shutdown Reboot if the livelock forces a crash and restart, though it is primarily a stability issue rather than an exploit vector for privilege escalation. The fix also references similar quirks found in 8250_omap via UART_RX_TIMEOUT_QUIRK and notes regarding 8250_bcm7271, indicating that this class of hardware bug requires explicit driver-level workarounds to maintain system stability across diverse embedded Linux deployments.