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

Report a missing map key distinctly from a failed lookup

Public commit record

What the developer wrote

Authored by Salvatore Ingala

83/100 · Strong
Report a missing map key distinctly from a failed lookup

Reading a value by key out of a merkleized map has two outcomes that
callers must tell apart: the key is genuinely not in the map (normal for
every optional PSBT field), or the lookup failed (Merkle proof mismatch,
malformed client response, transport error).

Previously, the API collapsed both into a single negative return, so a
caller applying a default for an optional field would also apply it
after a proof failure, swallowing what should logically be an error.

The shared contract lives in the new map_value_status.h, which also
documents that MAP_VALUE_ABSENT is a client assertion and not a proof:
the device requests no proof of absence, so a suppressed key is
indistinguishable from an honest omission. Where soundness is required,
presence must be derived from the key enumeration performed while
validating the map, which is committed to by keys_root.

No caller behaviour changes here: every current caller tests `< 0`, which
stays correct. Three tests that pinned the old granular codes now assert
the named ones, and the not-found test is strengthened from `< 0` to
MERKLE_LEAF_NOT_FOUND.
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Mentions testing or verification
The short version

What changed, and why it matters

This commit fixes a design bug in how the Ledger Bitcoin app asks a connected computer for data stored in a cryptographic map (used for PSBT transaction fields). Previously, 'key genuinely missing' and 'lookup failed due to a bad proof or communication error' were reported the same way. That meant the app could silently apply a default value when it should have rejected a faulty response. The patch separates the two cases so future callers can tell them apart, though existing callers still use the old '< 0' check and are not changed here. The commit also documents that 'missing key' is only what the host claims, not a cryptographic proof.

Recommended action

Review all current and future callers of the three map-value functions to ensure they branch explicitly on MAP_VALUE_ABSENT when applying defaults for optional PSBT fields, rather than using res < 0. Consider backporting the status-code contract to any release branches that may later add callers. Continue strengthening unit tests for proof-of-absence vs. failure cases.

Security signals we found

01

Ambiguous error handling between missing optional key and lookup failure

02

Merkle proof failure could be swallowed as 'key not found'

03

Client assertion of absence is explicitly not cryptographically verified

04

New status contract added to prevent default-value fallback on errors

05

Unit tests strengthened to distinguish not-found from error conditions

Risk score

Why this scored 50/100

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