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().
{
"cna_assigner": "zephyr",
"cwe_ids": [
"CWE-835"
],
"osv_generated_from": "https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/12xxx/CVE-2026-12629.json"
}"https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2026-12629.json"
[
{
"deprecated": false,
"digest": {
"function_hash": "196083385552469378206861632426548128477",
"length": 357
},
"id": "CVE-2026-12629-71449d00",
"signature_type": "Function",
"signature_version": "v1",
"source": "https://github.com/zephyrproject-rtos/zephyr/commit/1069b6822ac90da2b9e6dc8a5bbe3873e9f92818",
"target": {
"file": "drivers/serial/uart_pl011.c",
"function": "pl011_err_check"
}
},
{
"deprecated": false,
"digest": {
"function_hash": "136274642411092818019434371297512601918",
"length": 99
},
"id": "CVE-2026-12629-bf8ca5b1",
"signature_type": "Function",
"signature_version": "v1",
"source": "https://github.com/zephyrproject-rtos/zephyr/commit/1069b6822ac90da2b9e6dc8a5bbe3873e9f92818",
"target": {
"file": "drivers/serial/uart_pl011.c",
"function": "pl011_irq_is_pending"
}
},
{
"deprecated": false,
"digest": {
"line_hashes": [
"139431015106148378396021754643844722688",
"308507001222748425192340972266585222380",
"273294261789910716871931305324536809637",
"336926431878144320005218417783849254542",
"185318813110274884078683294066805360969",
"183474012705003906845971121393478412630",
"137466254033374017991487689023284469495",
"333516226850468898736923800302338029607",
"81395974098477622823219234870948913265",
"151077784960088525060246169994615445245",
"311530687496949764492142646138491668161",
"91470339982675920069924188095993912569"
],
"threshold": 0.9
},
"id": "CVE-2026-12629-bf932e0d",
"signature_type": "Line",
"signature_version": "v1",
"source": "https://github.com/zephyrproject-rtos/zephyr/commit/1069b6822ac90da2b9e6dc8a5bbe3873e9f92818",
"target": {
"file": "drivers/serial/uart_pl011.c"
}
},
{
"deprecated": false,
"digest": {
"function_hash": "19262635546237297589956869814571089434",
"length": 329
},
"id": "CVE-2026-12629-d1ed468b",
"signature_type": "Function",
"signature_version": "v1",
"source": "https://github.com/zephyrproject-rtos/zephyr/commit/1069b6822ac90da2b9e6dc8a5bbe3873e9f92818",
"target": {
"file": "drivers/serial/uart_pl011.c",
"function": "pl011_isr"
}
}
]
"2026-08-28T14:32:58Z"