Ledger Bitcoin app

This commit simply turns on Link Time Optimization (LTO), a standard compiler feature that can make the app smaller and faster. There is no indication of a security bug or fix in the change itself or the commit message.

This commit adds support for using MuSig multi-signature key groups inside taproot multi_a wallet policies on Ledger devices, while deliberately blocking them in sortedmulti_a. It also fixes a subtle parsing bug: previously, key expressions inside multi_a/sortedmulti_a were allocated one-by-one in a memory buffer, which would interleave badly with MuSig's own allocations and corrupt the in-memory layout. The new code parses all the keys into a temporary stack array first, then copies them into one contiguous allocation. Separately, the 'cleartext' human-readable display module now refuses to classify multisig patterns that contain musig keys, so the device falls back to showing the raw descriptor instead of potentially misleading text (for example, showing 'any 1 of two keys' for a musig that actually requires both).

This commit hardens Ledger's Bitcoin app so that when it asks the host computer for Merkle-tree data and the request fails or the data is rejected, the memory buffer that was supposed to receive the data is wiped clean with zeros. Before the change, an attacker-controlled host could leave chosen bytes in that buffer even after the app decided the data was invalid. The patch is a defense-in-depth measure; it does not by itself fix a known exploitable bug, but it removes a class of subtle mistakes where later code might accidentally trust leftover hostile data.

This commit adds a new developer-only fuzzing test framework to the Ledger Bitcoin app. It does not change how the app behaves on a real device; it only adds automated test infrastructure that feeds random or structured inputs to the app in a simulated environment to help find bugs. There is no indication this commit fixes or introduces a security vulnerability in production code.

This commit only adds a new automated test, plus screen snapshots used by that test. The test checks that after signing a Bitcoin transaction (PSBT), then signing a text message, the device does not accidentally reuse leftover display settings from the previous operation. The commit message says the test would have failed on an older version of the app, implying a prior UI bug existed. However, this commit itself does not change the app code, so it is not a fix and cannot be directly exploited. It is a regression test that documents a previous display-state issue.

This commit is a hardening and refactor of the code that reads PSBT (Partially Signed Bitcoin Transaction) fields from a host computer into a Ledger hardware wallet. The core security fix is that the device now clearly distinguishes between a field that is genuinely missing in a PSBT map and a field that is present but malformed or failed to verify. Previously, both cases could return the same error code, which could trick the wallet into silently using a default value (for example, default nSequence or default locktime) when the host had actually committed to something else. The commit also adds a guard that refuses to look up values by key unless the map's keys have already been proven to be sorted and unique, preventing a malicious host from supplying two different values for the same key.

This commit fixes a security hygiene issue in Ledger's Bitcoin app when reading PSBT (Partially Signed Bitcoin Transaction) data fields. Previously, if a field was missing or malformed, the memory buffer meant to hold the field value could be left containing leftover or partially written data controlled by the host/device communicating with the Ledger. The change ensures the buffer is explicitly wiped to zero and its reported length is reset in those failure cases, so callers cannot accidentally use stale or incorrect data. The commit message itself states this avoids leaving 'host-controlled bytes in memory in cases of failure.'

This commit is a small follow-up cleanup to a previous pull request. It adds one safety step before validating a sorted key map, clarifies documentation about when missing map keys can be trusted, updates a copyright year, tightens a size check on a Bitcoin transaction field, and removes an oversized temporary buffer. The changes look like defensive hardening rather than a fix for an active bug, and the commit message gives no security context.

This commit changes how on-screen text labels are prepared on Ledger's newer Bitcoin app interface. Previously, only the text fields were updated, leaving other hidden struct fields carrying whatever values were left over from earlier screens. The patch now resets the entire struct each time, preventing stale hidden settings (like centered layout flags or icons) from leaking between different app screens. The risk is mainly that a leftover flag could subtly alter what the user sees or how a confirmation page is rendered, potentially confusing a user at the moment they approve a transaction.

This commit is a code cleanup in Ledger's Bitcoin app. It replaces a memory-saving 'relative pointer' scheme with ordinary C pointers in the wallet-policy data structures. The change removes several hundred lines of pointer-conversion code and adds one compile-time check to make sure key-expression structures stay properly aligned when allocated back-to-back. There is no direct evidence in the commit that it fixes an active security bug; it reads as a maintainability/refactoring change to reduce complexity on newer Ledger devices that have more RAM.

This commit increases the memory buffers used to store parsed Bitcoin wallet policies inside Ledger's Bitcoin app. It is a preparatory change for an upcoming internal refactor that will make the policy data structure larger. The change itself does not fix a known bug or vulnerability, but it adjusts memory limits to avoid future out-of-memory failures. The Nano X keeps a smaller buffer than other devices, which the commit notes could cause some very complex policies to be rejected.

This commit fixes a bug in Ledger's Bitcoin app where malformed PSBT data could silently be treated as if it were missing. Specifically, if the 'nSequence' or 'fallback locktime' fields were present but unreadable (wrong length or bad proof), the app previously substituted default values and continued signing. Now it correctly rejects such malformed inputs. This prevents a malicious or buggy wallet client from getting the device to sign a transaction using sequence or locktime values the client never actually committed to.

This commit is a code cleanup (refactor) in Ledger's Bitcoin app. It moves the logic for reading PSBT (Partially Signed Bitcoin Transaction) fields into dedicated helper functions with clearer success/error/absent status codes. The author explicitly states there is no behavior change; the patch preserves existing handling of two optional fields exactly as before, with fixes for those edge cases planned in a follow-up commit. The changes add unit tests and improve code clarity, but do not by themselves fix a security bug.

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.

This commit hardens a Ledger Bitcoin app security check. Previously, reading a value from a special data structure (a 'merkleized map') by key required the caller to first verify that all keys were sorted and unique; that was only a documented rule, not enforced. A malicious host could potentially trick the app into reading the wrong value for a key if the rule was skipped. The patch now tracks a 'keys are sorted' flag inside the map commitment itself and makes all by-key readers fail (via an internal assertion) if that flag is not set. It also adds a helper to validate maps that come directly from the APDU command (like the PSBT global map).

This commit fixes several low-level programming bugs in Ledger's Bitcoin app that were found by automated fuzzing. The bugs include a dangerous bit shift, a pointless memory move with zero bytes, and incorrect comparisons between signed and unsigned numbers when parsing transaction data and signing PSBTs. Most fixes are defensive hardening, but one change moves a sanity check earlier so the app rejects absurdly large input amounts before adding them up, which could prevent an overflow. The commit does not claim these are directly exploitable attacks, but they remove undefined behavior that could in theory lead to crashes or incorrect signing.

This commit tightens validation of a Bitcoin transaction signing field. The Ledger app previously accepted any non-error value when reading the PSBT_IN_PREVIOUS_TXID field, even if it was shorter or longer than the required 32 bytes. Now it rejects any length other than exactly 32 bytes. An incorrect txid length could let a malformed or malicious PSBT misrepresent which previous transaction is being spent, potentially leading to signing the wrong transaction data.

This commit adds a new developer-only fuzzing test framework for the Ledger Bitcoin app. It does not change any production wallet, signing, or transaction-handling code. Instead, it introduces mock functions, test harnesses, build scripts, and documentation so automated tools can throw randomized inputs at the app in a controlled way to find bugs. There is no indication this commit fixes a security bug or introduces a vulnerability in shipped firmware.

This commit only changes how the app's internal fuzz-testing harness behaves. It does not alter normal production behavior. The changes add compile-time guards so that certain safety relaxations (like skipping duplicate-public-key checks or forcing swap checks to run) are active only when the code is built in a special fuzzing mode. One small non-fuzzing change moves a Bech32 character table from a pointer into read-only data, which is a hardening improvement but not a fix for an exploitable vulnerability.

This commit fixes missing error handling in the Ledger Bitcoin app's MuSig2 multi-signature code. Several cryptographic functions could fail silently or return incorrect results because their error codes were ignored. The patch now checks those return values and aborts the signing process when something goes wrong. It also corrects a debug-print index so a disruptive co-signer is reported with the right number.

This commit fixes three places in the Ledger Bitcoin app's MuSig2 code where the result of an elliptic-curve point-addition operation was not checked for failure. If point_add fails (for example, because it produced the special 'point at infinity' or another error condition), the code previously continued using an invalid public key or nonce. The patch now aborts the signing operation and returns an error. It also corrects a debug-print index that was off by one and makes a type conversion explicit.

This commit fixes a small but meaningful bug in the Ledger Bitcoin app's code that handles advanced multi-signature (MuSig) operations. A function called crypto_tr_lift_x can fail when given an invalid x-coordinate that does not correspond to any real point on the Bitcoin elliptic curve. Previously, the cpoint function ignored that failure and kept using the resulting output as if it were valid. The patch now checks the return value, prints an error message, and returns an error code instead of continuing with potentially bad data. In a hardware wallet, using invalid curve points could in theory lead to incorrect signature calculations or unexpected behavior, though the practical exploit path is not fully clear from the diff alone.

This update fixes a stack-exhaustion weakness in Ledger's Bitcoin app. A malicious or unusually crafted wallet policy (the text string that describes how coins can be spent) could make the app recurse so deeply that it runs out of call stack and crashes. The patch adds depth limits during parsing, reduces large on-stack buffers, and moves big buffers out of recursive functions so the app rejects oversized policies safely instead of crashing.

This commit rewrites a function in the Ledger Bitcoin app to use less memory. The old code stored a large table of key-derivation pairs for every possible class of key expression, which grew quadratically with the maximum number of key expressions. The new code stores only the class assignment for each key expression and rebuilds the pair list one class at a time, cutting stack usage by several kilobytes. The change also narrows some integer types. There is no explicit security bug fixed in the commit message, but on memory-constrained hardware large stack frames can contribute to crashes or stack overflows.

This commit refactors the Ledger Bitcoin app's wallet registration code so that the user-confirmation step runs in a separate function that the compiler is told not to inline. The stated goal is to reduce peak stack memory use by freeing large validation buffers before the UI rendering phase. The change itself is a defensive hardening/optimization patch; there is no direct evidence in the commit that it fixes an exploitable vulnerability.