Description

The ARM PL011 UART driver in drivers/serial/uart_pl011.c fails to acknowledge receive error interrupts. On the PL011, the framing, parity, break, and overrun error interrupts (PL011_IMSC_ERROR_MASK) are cleared only by writing the interrupt-clear register UARTICR; reading the data register clears the RX interrupt and the per-byte RSR status but not the error interrupt status in MIS. The interrupt service routine pl011_isr() acknowledged only the CTS modem-status interrupt and never wrote icr for the error bits, so an asserted error interrupt remains pending after the ISR returns. When an application enables error-interrupt reporting via the public uart_irq_err_enable() API, an attacker who controls the serial peer can deterministically assert these error bits by injecting line errors on the RX line — a baud/stop-bit mismatch or mid-character break (framing/break error), a flipped parity bit (parity error), or FIFO flooding (overrun error). Because the error interrupt is never cleared, the interrupt line stays asserted and the CPU re-enters pl011_isr() immediately and indefinitely, producing an interrupt-storm livelock from which the core makes no forward progress. The impact is an availability-only denial of service (permanent hang), reachable from an external or removable UART peer. Exploitation is gated by configuration: the error interrupt is off by default and no in-tree subsystem enables it, so only applications that explicitly call uart_irq_err_enable() on a PL011-based, interrupt-driven port are affected. The fix makes pl011_isr() acknowledge the pending error bits via uart->icr, breaking the loop, and additionally clears the latched RSR status in pl011_err_check().

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "4.6",
  "pubDate": "2026-08-17T17:16:39.010Z",
  "pubdate": "2026-08-17T17:16:39.010Z",
  "executiveSummary": "A denial of service vulnerability exists in the ARM PL011 UART driver, specifically within the drivers/serial/uart_pl011.c file. The flaw is classified as an improper interrupt handling vulnerability that results in an availability-only permanent hang via an interrupt-storm livelock.\nThe vulnerability impacts systems utilizing the ARM PL011 UART driver in interrupt-driven configurations where applications explicitly enable error-interrupt reporting via the public uart_irq_err_enable() API.\nAn external or removable serial peer attacker capable of interacting with the UART interface can exploit this vulnerability. By injecting line errors—such as framing, parity, break, or overrun errors—the attacker can cause the interrupt service routine to fail to clear the error status.\nThis leaves the error interrupt permanently pending, forcing the CPU to continuously re-enter the pl011_isr() routine indefinitely and preventing the core from making any forward progress.\nExploitation is strictly gated by system configuration: the error interrupt is disabled by default, and no in-tree subsystems enable it natively, meaning only applications that explicitly activate error interrupt reporting are susceptible to the attack.",
  "technicalDetails": "The root cause of the vulnerability lies in the improper handling of receive error interrupts within the pl011_isr() interrupt service routine located in drivers/serial/uart_pl011.c. On the ARM PL011 hardware architecture, framing, parity, break, and overrun error interrupts, collectively defined by PL011_IMSC_ERROR_MASK, can only be cleared by explicitly writing to the interrupt-clear register UARTICR.\nStandard data register reads clear the regular RX interrupt and the per-byte receive status register (RSR) status, but they fail to clear the error interrupt status registered in the masked interrupt status (MIS) register. Historically, the pl011_isr() function only acknowledged the CTS modem-status interrupt and omitted the necessary write operation to the icr register for error bits.\nConsequently, if an error bit is asserted, the interrupt line remains asserted continuously after the ISR returns. The attack flow proceeds as follows: an attacker controlling the serial peer injects physical line errors on the RX line. This can be achieved deterministically by generating a baud or stop-bit mismatch or a mid-character break to trigger framing and break errors, flipping a parity bit to induce a parity error, or flooding the FIFO to create an overrun error.\nWhen an application enables error-interrupt reporting through the public uart_irq_err_enable() API, the system becomes vulnerable. Upon receiving the injected line errors, the hardware asserts the error interrupt. Because pl011_isr() fails to acknowledge or clear the pending error bits via uart->icr, the CPU immediately and indefinitely re-enters pl011_isr() upon exiting, triggering a catastrophic interrupt-storm livelock.\nThis behavior creates a total denial of service condition affecting system availability, freezing the execution core entirely. The vulnerability requires physical or logical proximity to the serial UART interface to inject the malicious line errors, and authentication or privilege requirements are dependent on the underlying operating system's exposure of serial peripheral control to unprivileged entities."
}