fix(zcash): initialize batch parse fingerprint
What the developer wrote
Authored by Adam Tucker
fix(zcash): initialize batch parse fingerprint
What changed, and why it matters
This commit fixes a small but meaningful bug in the Keystone hardware wallet's Zcash batch transaction screen. A 32-byte fingerprint buffer (`sfp`) was used without being initialized to zero. The code then fills it via `GetZcashSFP`, but if that function fails or does not fully write all 32 bytes, leftover memory contents could be used. In a security device, using uninitialized memory for a fingerprint/checksum can lead to incorrect verification results, unpredictable behavior, or in the worst case leak sensitive memory contents. The fix simply ensures the buffer starts as all zeros.
Review all callers of `GetZcashSFP` and similar fingerprint helpers to ensure output buffers are initialized and return values are checked. Consider adding unit tests that simulate failure/partial-write paths. If this code path is reachable from untrusted data (e.g., parsing a QR/air-gapped transaction), treat as a low-to-moderate security issue and include in release notes.
Security signals we found
Uninitialized local buffer used for cryptographic/identity fingerprint
Potential information disclosure or verification bypass if helper function fails partially
Fix pattern is a one-line initialization, indicating a partial/spot fix rather than systemic audit
Located in hardware-wallet Zcash batch UI code, a high-value target for transaction integrity
Evidence from the diff
In src/ui/gui_widgets/multi/cypherpunk/gui_zcash_batch_widgets.c, the local uint8_t sfp[32] was declared without initialization. It is later populated by GetZcashSFP(GetCurrentAccountIndex(), sfp). If GetZcashSFP does not write the full buffer on error paths, sfp may contain stack garbage. Because sfp appears to be a seed fingerprint used for transaction/address verification in Zcash batch operations, uninitialized data could cause verification mismatches or, if the buffer is later displayed/serialized, information disclosure. The patch changes the declaration to uint8_t sfp[32] = {0};, guaranteeing deterministic initial contents.
Changed components
src/ui/gui_widgets/multi/cypherpunk/gui_zcash_batch_widgets.cZcash batch transaction parsing/verification UIGetZcashSFP fingerprint handlingInspect captured patch +1 / −1
diff --git a/src/ui/gui_widgets/multi/cypherpunk/gui_zcash_batch_widgets.c b/src/ui/gui_widgets/multi/cypherpunk/gui_zcash_batch_widgets.c
index 24b1e1c..be36947 100644
--- a/src/ui/gui_widgets/multi/cypherpunk/gui_zcash_batch_widgets.c
+++ b/src/ui/gui_widgets/multi/cypherpunk/gui_zcash_batch_widgets.c
@@ -406,7 +406,7 @@ static void *GuiParseZcashBatchData(void)
free_TransactionCheckResult(checkResult);
}
- uint8_t sfp[32];
+ uint8_t sfp[32] = {0};
GetZcashSFP(GetCurrentAccountIndex(), sfp);
char ufvk[ZCASH_UFVK_BUFFER_SIZE] = {0};
Why this scored 35/100
Community notes
Notes can correct, qualify, or add evidence to the AI analysis. Every note shown here has been validated by a human moderator.
The AI analysis stands alone for now. Submit a note if you can add evidence or important context.