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

fix(core): store packet across session restart during channel preemption

Public commit record

What the developer wrote

Authored by Martin Milata

77/100 · Adequate
fix(core): store packet across session restart during channel preemption

This way TRANSPORT_BUSY is not sent and host doesn't have to retransmit
the packet.

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

What changed, and why it matters

This commit fixes a behavior in Trezor's core firmware where, during a 'channel preemption' (one computer taking over communication with the device from another), the device would send a TRANSPORT_BUSY message and force the new host to resend its packet. The fix stores the incoming packet across the session restart so it can be processed automatically, avoiding the unnecessary busy signal and retransmission. It is a robustness/usability improvement in the device's USB/transport layer rather than a fix for a clear-cut security vulnerability.

Recommended action

Review as a normal bugfix/robustness improvement. Verify that the global PreemptingPacket buffer cannot be abused across interfaces (it is keyed by iface_num and rejects a second set() while full, which limits cross-interface confusion). Confirm that buffer length is capped at MAX_PACKET_LEN (244 bytes) and that the memoryview is consumed before the next set(). No immediate security response is indicated by the diff alone.

Security signals we found

01

Avoids TRANSPORT_BUSY race/retransmission during channel preemption

02

Adds global mutable buffer for a single in-flight packet across session restart

03

Kills active channel with ChannelPreemptedException before storing packet

04

New tests verify timing-dependent preemption behavior

05

No changelog entry despite functional behavior change

Risk score

Why this scored 37/100

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