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

fix(zcash): error handling in setup functions

Public commit record

What the developer wrote

Authored by John Boyd

80/100 · Strong
fix(zcash): error handling in setup functions

- Check return values of SetupZcashCache/SetupZcashSFP and
AccountPublicInfoSwitch in CreateNewAccount and VerifyPasswordAndLogin
- Fix seed buffer leaks in SetupZcashSFP and SetupZcashCache error paths
- Fix wrong variable (response -> responseSFP) in SetupZcashCache
SFP error path
- Free response objects before returning on error
- Clear UFVK buffer after use
- Check for NULL encrypted UFVK before decryption

Co-authored-by: Daira-Emma Hopwood <daira@jacaranda.org>
Co-authored-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
✓ 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 fixes several bugs in the Zcash wallet setup code for a hardware wallet. Previously, the code could ignore errors when setting up Zcash data, leak sensitive seed material in memory, use the wrong error variable, and try to decrypt a missing encrypted key. These are reliability and security hygiene issues rather than a single obvious remote exploit, but they could let a device finish account creation or login even though Zcash keys were not set up correctly, and could leave secret seed bytes in memory longer than intended.

Recommended action

Treat this as a security-hardening fix and include it in the next firmware release. Review other Rust FFI response wrappers for similar missing free/clear patterns, and consider adding static analysis rules to enforce return-value checks and secure buffer clearing for seed/UFVK handling.

Security signals we found

01

Unchecked return values in security-critical setup functions

02

Sensitive buffer (seed) not cleared on error paths

03

Use of wrong variable in error-handling path (response vs responseSFP)

04

Missing NULL check before decrypting encrypted UFVK

05

Memory/object leaks of response structs on error paths

06

UFVK plaintext left in stack buffer after use

Risk score

Why this scored 59/100

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