fix(core): clear THP channel after `DEVICE_LOCKED` error
What the developer wrote
Authored by Roman Zeyde
fix(core): clear THP channel after `DEVICE_LOCKED` error
It should fix the issue described here:
https://github.com/trezor/trezor-firmware/issues/5885#issuecomment-3345712654
(causing alternating `ThpTransportBusy` and `ThpDeviceLocked` errors)
Currently the device allocates THP buffers to the first channel
receiving a message after an event loop restart.
This is a simple workaround for the above issue, since `ThpDeviceLocked`
happens only during THP handshake, and if it happens, the host will
create and use a new channel.
[no changelog]
What changed, and why it matters
This is a small bug fix in the Trezor hardware wallet firmware. It clears a temporary communication channel when the device reports it is locked during a specific handshake process. Without the fix, the device could get stuck alternating between two error states, potentially disrupting normal USB communication and requiring a reconnect or restart. There is no direct evidence this can be used to steal funds, but any disruption to a security device's communication channel is treated cautiously.
Treat as a reliability/availability fix with possible security-adjacent denial-of-service implications. Users should update firmware when a release containing this commit is available. Developers should follow the linked issue and consider a root-cause fix for THP buffer allocation after event loop restart.
Security signals we found
Resource not released after error path (THP channel/buffer remains allocated)
Error-state alternation (`ThpTransportBusy` / `ThpDeviceLocked`) indicates state-machine inconsistency
Communication protocol handshake failure path patched
No changelog entry provided by vendor
Fix is described as a workaround, not a root-cause fix
Evidence from the diff
In core/src/trezor/wire/thp/received_message_handler.py, after the device writes a ThpErrorType.DEVICE_LOCKED error during THP (Trezor Host Protocol) handshake, the patch now calls channel.clear(). Previously, the THP buffers remained allocated to the first channel that received a message after an event loop restart. This caused an alternating ThpTransportBusy / ThpDeviceLocked error loop because the stale channel still held resources while the host tried to open a new channel. The fix is described as a workaround; the underlying allocation behavior is not changed.
Changed components
core/src/trezor/wire/thp/received_message_handler.pyTrezor Host Protocol (THP) handshake layerTHP channel/buffer allocatorInspect captured patch +1 / −0
diff --git a/core/src/trezor/wire/thp/received_message_handler.py b/core/src/trezor/wire/thp/received_message_handler.py
index 5a0d9881f..dcfc4fdd2 100644
--- a/core/src/trezor/wire/thp/received_message_handler.py
+++ b/core/src/trezor/wire/thp/received_message_handler.py
@@ -75,6 +75,7 @@ async def handle_received_message(channel: Channel) -> bool:
await channel.iface_ctx.write_error(
channel.get_channel_id_int(), ThpErrorType.DEVICE_LOCKED
)
+ channel.clear()
return False
Why this scored 37/100
Community notes
Notes can correct, qualify, or add evidence to the AI analysis. Every note shown here has been validated by a human moderator.
The AI analysis stands alone for now. Submit a note if you can add evidence or important context.