CVE-2026-12629
Full vulnerability record from the local CVENow database.
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().
View original CVE JSON
{
"id": "CVE-2026-12629",
"sourceIdentifier": "[email protected]",
"published": "2026-08-17T17:16:39.010",
"lastModified": "2026-10-23T16:10:00.313",
"vulnStatus": "Awaiting Analysis",
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "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.\n\nWhen 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.\n\nThe 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()."
},
{
"lang": "es",
"value": "El controlador UART ARM PL011 en drivers/serial/uart_pl011.c no reconoce las interrupciones de error de recepción. En el PL011, las interrupciones de error de encuadre, paridad, ruptura y desbordamiento (PL011_IMSC_ERROR_MASK) se borran solo escribiendo en el registro de borrado de interrupciones UARTICR; la lectura del registro de datos borra la interrupción RX y el estado RSR por byte, pero no el estado de interrupción de error en MIS. La rutina de servicio de interrupción pl011_isr() reconoció solo la interrupción de estado de módem CTS y nunca escribió icr para los bits de error, por lo que una interrupción de error afirmada permanece pendiente después de que la ISR regresa.\n\nCuando una aplicación habilita la notificación de interrupciones de error a través de la API pública uart_irq_err_enable(), un atacante que controla el par serie puede afirmar determinísticamente estos bits de error inyectando errores de línea en la línea RX - una falta de coincidencia de baudios/bit de parada o una ruptura a mitad de carácter (error de encuadre/ruptura), un bit de paridad invertido (error de paridad), o un desbordamiento de FIFO (error de desbordamiento). Debido a que la interrupción de error nunca se borra, la línea de interrupción permanece afirmada y la CPU vuelve a entrar en pl011_isr() de forma inmediata e indefinida, produciendo un bloqueo por tormenta de interrupciones desde el cual el núcleo no realiza ningún progreso.\n\nEl impacto es una denegación de servicio solo de disponibilidad (cuelgue permanente), alcanzable desde un par UART externo o extraíble. La explotación está condicionada por la configuración: la interrupción de error está desactivada por defecto y ningún subsistema en el árbol la habilita, por lo que solo las aplicaciones que llaman explícitamente a uart_irq_err_enable() en un puerto basado en PL011 y controlado por interrupciones se ven afectadas. La solución hace que pl011_isr() reconozca los bits de error pendientes a través de uart -> icr, rompiendo el bucle, y adicionalmente borra el estado RSR enclavado en pl011_err_check()."
}
],
"affected": [
{
"source": "[email protected]",
"affectedData": [
{
"vendor": "zephyrproject",
"product": "zephyr",
"defaultStatus": "unaffected",
"collectionURL": "https://github.com/zephyrproject-rtos/zephyr",
"packageName": "zephyr",
"programFiles": [
"drivers/serial/uart_pl011.c"
],
"versions": [
{
"version": "1.14.0",
"lessThan": "4.4.2",
"versionType": "semver",
"status": "affected"
}
]
}
]
}
],
"metrics": {
"cvssMetricV31": [
{
"source": "[email protected]",
"type": "Secondary",
"cvssData": {
"version": "3.1",
"vectorString": "CVSS:3.1/AV:P/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"baseScore": 4.6,
"baseSeverity": "MEDIUM",
"attackVector": "PHYSICAL",
"attackComplexity": "LOW",
"privilegesRequired": "NONE",
"userInteraction": "NONE",
"scope": "UNCHANGED",
"confidentialityImpact": "NONE",
"integrityImpact": "NONE",
"availabilityImpact": "HIGH"
},
"exploitabilityScore": 0.9,
"impactScore": 3.6
}
],
"ssvcV203": [
{
"source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"ssvcData": {
"timestamp": "2026-08-17T18:26:54.616442Z",
"id": "CVE-2026-12629",
"options": [
{
"exploitation": "none"
},
{
"automatable": "no"
},
{
"technicalImpact": "partial"
}
],
"role": "CISA Coordinator",
"version": "2.0.3"
}
}
]
},
"weaknesses": [
{
"source": "[email protected]",
"type": "Secondary",
"description": [
{
"lang": "en",
"value": "CWE-835"
}
]
}
],
"references": [
{
"url": "https://github.com/zephyrproject-rtos/zephyr/commit/1069b6822ac90da2b9e6dc8a5bbe3873e9f92818",
"source": "[email protected]"
},
{
"url": "https://github.com/zephyrproject-rtos/zephyr/security/advisories/GHSA-36rp-2hcp-f5hv",
"source": "[email protected]"
}
]
}