CVE-2026-10642
Full vulnerability record from the local CVENow database.
Description
The Zephyr PL011 UART driver (drivers/serial/uart_pl011.c) contains an unbounded software loop in pl011_irq_tx_enable() that repeatedly invokes the interrupt-driven application callback while the TX interrupt mask bit (PL011_IMSC_TXIM) is set, to work around the controller's level-transition TX-interrupt behavior. When CTS hardware flow control is enabled (devicetree hw-flow-control or runtime UART_CFG_FLOW_CTRL_RTS_CTS) and the wired serial peer de-asserts CTS, the controller stops draining the TX FIFO; pl011_fifo_fill() then returns 0 on every call while the application still has pending data and therefore never disables the TX interrupt. The loop condition never clears, so the thread that called uart_irq_tx_enable() (e.g. h4_send() in the Bluetooth HCI H4 driver) spins indefinitely, hanging the executing context and stalling the transport — a denial of service (CWE-835). An attacker controlling the device attached to the UART's CTS line can trigger the hang by withholding CTS during transmission. Because that peer is the device wired to the UART — which may be a removable or external module (e.g. an off-board Bluetooth controller on the HCI H4 link) rather than a permanently-bonded on-PCB part — the attack vector is scored Adjacent (AV:A) rather than Physical; the security subcommittee should confirm the vector against the specific deployment. Impact is availability only; there is no memory-safety, confidentiality, or integrity consequence. The vulnerable loop was introduced in commit b783bc8448ef (Feb 2025) and shipped in releases v4.1.0 through v4.4.0. The fix breaks out of the loop when CTS is blocking and arms the CTS modem-status interrupt to resume transmission when CTS re-asserts.
View original CVE JSON
{
"id": "CVE-2026-10642",
"sourceIdentifier": "[email protected]",
"published": "2026-06-24T22:16:46.253",
"lastModified": "2026-10-25T23:10:00.167",
"vulnStatus": "Modified",
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "The Zephyr PL011 UART driver (drivers/serial/uart_pl011.c) contains an unbounded software loop in pl011_irq_tx_enable() that repeatedly invokes the interrupt-driven application callback while the TX interrupt mask bit (PL011_IMSC_TXIM) is set, to work around the controller's level-transition TX-interrupt behavior.\n\nWhen CTS hardware flow control is enabled (devicetree hw-flow-control or runtime UART_CFG_FLOW_CTRL_RTS_CTS) and the wired serial peer de-asserts CTS, the controller stops draining the TX FIFO; pl011_fifo_fill() then returns 0 on every call while the application still has pending data and therefore never disables the TX interrupt. The loop condition never clears, so the thread that called uart_irq_tx_enable() (e.g. h4_send() in the Bluetooth HCI H4 driver) spins indefinitely, hanging the executing context and stalling the transport — a denial of service (CWE-835).\n\nAn attacker controlling the device attached to the UART's CTS line can trigger the hang by withholding CTS during transmission. Because that peer is the device wired to the UART — which may be a removable or external module (e.g. an off-board Bluetooth controller on the HCI H4 link) rather than a permanently-bonded on-PCB part — the attack vector is scored Adjacent (AV:A) rather than Physical; the security subcommittee should confirm the vector against the specific deployment. Impact is availability only; there is no memory-safety, confidentiality, or integrity consequence.\n\nThe vulnerable loop was introduced in commit b783bc8448ef (Feb 2025) and shipped in releases v4.1.0 through v4.4.0. The fix breaks out of the loop when CTS is blocking and arms the CTS modem-status interrupt to resume transmission when CTS re-asserts."
},
{
"lang": "es",
"value": "El controlador UART Zephyr PL011 (drivers/serial/uart_pl011.c) contiene un bucle de software ilimitado en pl011_irq_tx_enable() que invoca repetidamente la devolución de llamada de la aplicación impulsada por interrupciones mientras el bit de máscara de interrupción TX (PL011_IMSC_TXIM) está establecido, para solucionar el comportamiento de interrupción TX de transición de nivel del controlador. Cuando el control de flujo de hardware CTS está habilitado (devicetree hw-flow-control o en tiempo de ejecución UART_CFG_FLOW_CTRL_RTS_CTS) y el par serie cableado desactiva CTS, el controlador deja de vaciar la FIFO TX; pl011_fifo_fill() entonces devuelve 0 en cada llamada mientras la aplicación todavía tiene datos pendientes y por lo tanto nunca deshabilita la interrupción TX. La condición del bucle nunca se borra, por lo que el hilo que llamó a uart_irq_tx_enable() (por ejemplo, h4_send() en el controlador Bluetooth HCI H4) gira indefinidamente, colgando el contexto de ejecución y deteniendo el transporte - una denegación de servicio (CWE-835). Un atacante que controla el dispositivo conectado a la línea CTS del UART puede desencadenar el cuelgue al retener CTS durante la transmisión. El impacto es solo la disponibilidad; no hay consecuencias de seguridad de la memoria, confidencialidad o integridad. El bucle vulnerable fue introducido en el commit b783bc8448ef (Feb 2025) y distribuido en las versiones v4.1.0 a v4.4.0. La solución sale del bucle cuando CTS está bloqueando y activa la interrupción de estado del módem CTS para reanudar la transmisión cuando CTS se reafirma."
}
],
"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": "4.1.0",
"lessThan": "4.3.1",
"versionType": "semver",
"status": "affected"
},
{
"version": "4.4.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-06-25T13:11:19.751133Z",
"id": "CVE-2026-10642",
"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"
}
]
},
{
"source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"type": "Secondary",
"description": [
{
"lang": "en",
"value": "CWE-835"
}
]
}
],
"configurations": [
{
"nodes": [
{
"operator": "OR",
"negate": false,
"cpeMatch": [
{
"vulnerable": true,
"criteria": "cpe:2.3:o:zephyrproject:zephyr:*:*:*:*:*:*:*:*",
"versionStartIncluding": "4.1.0",
"versionEndExcluding": "4.5.0",
"matchCriteriaId": "126A079E-DBC1-4B1D-AE33-D21D14520336"
}
]
}
]
}
],
"references": [
{
"url": "https://github.com/zephyrproject-rtos/zephyr/commit/68e702294b711eadfe7b4fadedd46d7c87fe8f3d",
"source": "[email protected]",
"tags": [
"Patch"
]
},
{
"url": "https://github.com/zephyrproject-rtos/zephyr/security/advisories/GHSA-3fgh-73jh-2q5j",
"source": "[email protected]",
"tags": [
"Exploit",
"Patch",
"Vendor Advisory"
]
}
]
}