AI-generated analysisPublished automatically and not human-verified. Validated context appears in community notes below.
← Watch feed
Low 34 Bitcoin

feat(core): reimplement THP retransmissions

Public commit record

What the developer wrote

Authored by Roman Zeyde

57/100 · Thin
feat(core): reimplement THP retransmissions

[no changelog]
✓ Descriptive subject✓ Names a concrete action or component✓ Uses a recognizable type or scope! No meaningful explanatory body
The short version

What changed, and why it matters

This commit finishes a previously stubbed-out feature in Trezor's core firmware: automatic retransmission of lost USB packets during a secure protocol called THP. Before this change, the code had a TODO comment where retransmissions should have been. After this change, the device will resend a packet up to 50 times with an increasing timeout if it does not receive an acknowledgment. This is a normal reliability improvement, but because it touches low-level packet handling and timeout logic, it could introduce subtle bugs such as the device hanging, retrying forever in edge cases, or misinterpreting a delayed packet as a fresh one.

Recommended action

Treat as a feature commit, not an emergency patch. Reviewers should verify that the backoff timeout formula cannot overflow or produce negative values, that the 50-retry limit cannot be bypassed by a malicious host sending crafted control bytes, that `recv_payload` correctly distinguishes a delayed ACK for a previous transmission from a new message, and that the `Timeout` exception is only raised by the intended timeout and not by unrelated I/O cancellation. Fuzzing the THP state machine around retransmissions would be prudent.

Security signals we found

01

TODO comment replaced with active retransmission loop

02

New timeout parameter propagates through message-reassembly path

03

Maximum retransmission count bounded at 50

04

Sequence-bit flip only occurs after `is_sending_allowed` is true

05

Unexpected control bytes now logged in debug builds

06

Retransmission timeout raises `ThpError` after exhausting retries

Risk score

Why this scored 34/100

Our methodology →
Potential impact 8/30
Exploitability 6/25
Stealth signal 5/15
Affected reach 7/15
Confidence 5/10
Evidence quality 3/5
Human-validated context

Community notes

Notes can correct, qualify, or add evidence to the AI analysis. Every note shown here has been validated by a human moderator.

No validated notes yet.

The AI analysis stands alone for now. Submit a note if you can add evidence or important context.