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

feat(zcash): store checked_PCZT in C and drive display/sign from it

Public commit record

What the developer wrote

Authored by Adam Tucker

62/100 · Adequate
feat(zcash): store checked_PCZT in C and drive display/sign from it
✓ 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 refactors how the Keystone hardware wallet handles Zcash transaction data. Previously, the wallet parsed and signed directly from the raw incoming transaction data. Now it first runs a 'check' function that produces a validated intermediate object (checked_PCZT), stores that object, and uses it for both on-screen display and signing. The change also adds cleanup logic to free that stored object. This is a defensive code-quality improvement that reduces the chance the wallet will display one version of a transaction but sign a different one.

Recommended action

Review the Rust implementation of check_zcash_tx_multi_coins and check_zcash_tx_cypherpunk to confirm the checked_PCZT output is fully validated and that no path can return success while leaving g_checkedPczt uninitialized or partially initialized. Also verify that GuiGetZcashCheckResult is always called before display/signing and that FreeZcashMemory is invoked on UR result changes to prevent stale checked data being reused.

Security signals we found

01

Refactor to use a single validated intermediate representation for both display and signing

02

Addition of explicit cleanup/free path for the new checked_PCZT object

03

Function pointer casts added to align Rust FFI signers with C callback signatures

04

Potential TOCTOU or stale-data risk if g_checkedPczt is not freed/replaced atomically with the UR result it derives from

Risk score

Why this scored 26/100

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