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

fix(core): don't raise `ThpError` on low-level protocol errors

Public commit record

What the developer wrote

Authored by Roman Zeyde

85/100 · Strong
fix(core): don't raise `ThpError` on low-level protocol errors

`ThpError` ends up being sent over the protocol as `MessageType_Failure`,
but in case of a low-level problem (e.g. unexpected SEQ bit), it is
probably better to ignore the offending message.

We should also not raise `ThpError` when a function is called with invalid
arguments (e.g. bit value not being 0 or 1).

[no changelog]
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Uses a recognizable type or scope✓ Provides detailed explanatory context
The short version

What changed, and why it matters

This commit changes how the Trezor hardware wallet handles low-level communication errors in its new THP (Trezor Host Protocol) code. Previously, certain malformed or unexpected low-level packets would cause the device to raise a ThpError, which gets sent back to the host as a Failure message. The patch makes the device silently ignore many of these low-level problems instead—such as unexpected control bytes, wrong sequence bits, bad checksums, invalid broadcast lengths, and reassembly overruns. Some internal argument checks are also converted from raising errors to assert statements, which only run in debug builds and are removed in production firmware. The stated intent is to make the protocol more robust against noisy or malformed traffic, but it also reduces the device's visibility into potential attacks or protocol fuzzing.

Recommended action

Treat this as a defensive-hardening change that warrants review rather than an confirmed vulnerability. A security reviewer should verify that ignoring each of these low-level errors cannot lead to state desynchronization, replay acceptance, buffer misuse, or denial of service. In particular, confirm that: (1) the reassembler reset on overread cannot be abused to drop legitimate payloads; (2) ignored unexpected sequence bits do not allow replay or sequence-number confusion; (3) assert-based validation in control_byte.py and alternating_bit_protocol.py is not reachable from untrusted host input in release builds; and (4) broadcast-channel invalid checksum/length/control-byte returns do not allow channel allocation spoofing. Consider adding counters or rate-limiting so that persistent malformed traffic is detectable.

Security signals we found

01

Error-silencing: multiple protocol error paths converted from raising ThpError/Failure to logging (debug-only) and continuing/returning

02

Defense weakening: malformed packets (bad checksum, wrong length, unexpected control byte, bad sequence bit) are now ignored rather than rejected

03

Debug-only assertions replace runtime argument validation in control_byte.py and alternating_bit_protocol.py

04

Reassembly overread no longer raises but resets state and returns False

05

Potential DoS / state confusion risk: an attacker or glitching host can send malformed THP traffic without receiving a Failure response

06

No explicit security advisory, CVE, or researcher attribution in commit or supplied references

Risk score

Why this scored 46/100

Our methodology →
Potential impact 12/30
Exploitability 10/25
Stealth signal 8/15
Affected reach 7/15
Confidence 6/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.