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

feat(cardano): replace chunking with length+offset

Public commit record

What the developer wrote

Authored by Peter Jaško

62/100 · Adequate
feat(cardano): replace chunking with length+offset
✓ Specific, 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 rewrites how the Trezor device fetches the message payload during Cardano message signing. Instead of the host pushing fixed-size chunks to the device, the device now asks for a specific slice of data by sending a length and offset, and the host replies with exactly that slice. The change also removes the previous 1024-byte maximum payload size limit, so larger messages can now be signed. The code adds bounds checks on both sides, but because the device now requests the entire payload in one go, this could stress limited device RAM. There is no direct evidence in the commit that this fixes a reported security bug; it reads as a feature/refactoring change.

Recommended action

Treat this as a protocol-breaking change rather than a confirmed vulnerability fix. Review the new _get_payload_data implementation for memory exhaustion or integer-overflow risks on the embedded device, especially because it currently requests the full payload in one call. Ensure the host-side Python and Rust clients strictly validate device requests against the known payload length to avoid out-of-bounds reads. Re-run Cardano sign-message device tests and fuzz the length/offset fields. If this change is being backported, verify that old clients using the previous message types cannot accidentally trigger the new code path.

Security signals we found

01

Protocol redesign from push-chunking to pull-based length+offset data transfer

02

Removal of the MAX_CHUNK_SIZE / 'Payload too long to sign' limit in firmware

03

Addition of bounds checks: offset+length <= payload_size and len(response.data) == chunk_length

04

Device now requests the entire payload in a single allocation (comment notes 'regardless of RAM constraints')

05

Message type IDs reused: 339/340/341 now have different semantics and directions than before

06

No explicit security bug description or CVE reference in commit message or diff

Risk score

Why this scored 29/100

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