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

fix(core): don't raise `FirmwareError("button request ack pending")` on THP debug builds

Public commit record

What the developer wrote

Authored by Roman Zeyde

89/100 · Strong
fix(core): don't raise `FirmwareError("button request ack pending")` on THP debug builds

Otherwise, it may cause THP channel to desync due to double write.

[no changelog]
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Uses a recognizable type or scope✓ Provides an explanatory body✓ Explains rationale or failure mode
The short version

What changed, and why it matters

This commit changes how a Trezor hardware wallet handles an internal error condition during user interactions. In debug builds using the new THP (Trezor Host Protocol) communication channel, the device no longer crashes with a 'FirmwareError' when a button-acknowledgment state is still pending. Instead, it logs the issue and continues. The old behavior could cause the THP channel to become desynchronized because the error path might write to the channel twice. The fix prevents a possible communication desync but deliberately suppresses a previously fatal internal-consistency check.

Recommended action

Review whether suppressing the 'button request ack pending' check on THP could mask a real UI-state bug. Verify that the THP transport correctly handles the case where a button request was pending at layout teardown without a second write. Consider adding a regression test for the desync scenario and ensure the non-THP path still catches inconsistent states.

Security signals we found

01

THP channel desynchronization risk from double write

02

Internal consistency check (button_request_ack_pending) relaxed on THP debug builds

03

FirmwareError no longer raised for a pending button-request ack under THP

04

Debug-only code path (__debug__) affected

05

No changelog entry provided

Risk score

Why this scored 35/100

Our methodology →
Potential impact 8/30
Exploitability 5/25
Stealth signal 6/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.