BTC: invalid output multisig quorum can lock change to an unsatisfiable script

[BitHighlander]

Summary

The Bitcoin signing path validates 1 <= m <= n <= 15 for multisig inputs, but not for multisig outputs. A host can submit a PAYTOMULTISIG internal/change output with m > n; the firmware derives the output and signs a transaction paying to an impossible quorum.

Found while auditing PR #604 at exact head 1d446ccbc9cf32a6e499990e65bcf7b358f1325b (release/7.14.3-bitcoin-only against fork develop).

Evidence

• lib/firmware/signing.c:845-857 correctly rejects invalid input quorums.
• lib/firmware/signing.c:907-967 validates output field/script compatibility but never validates multisig.m, pubkeys_count, or m <= n.
• lib/firmware/transaction.c:617-645 and :648-680 accept m and n independently in 1..15, then compile/hash OP_m <keys> OP_n OP_CHECKMULTISIG; neither rejects m > n.
• lib/firmware/transaction.c:527-553 deliberately skips the internal-transfer address/path screen for PAYTOMULTISIG, so the invalid change destination is not independently disclosed as an address.

Impact

High — loss of funds. A malicious or compromised host can label the output as internal change and obtain a valid signature for a transaction whose change is locked to an unsatisfiable multisig quorum.

Acceptance criteria

• Reject every multisig output unless has_m && 1 <= m <= pubkeys_count <= 15.
• Enforce the same invariant inside both multisig compiler functions as defense in depth.
• Add native and device-level negative tests for m=0, n=0, m>n, and values above 15 on both external and internal outputs.
• Prove no serialized transaction or signature is returned after rejection.

[BitHighlander]

Resolved on PR #604 at exact reviewed head d842f1e. Signing output validation and both multisig compilers enforce has_m and 1 <= m <= n <= 15, so invalid external or change outputs cannot serialize or sign. Native and wire negative tests and both exact-head CI gates passed. Re-review attestation: #604 (comment). Leaving this issue open until merge.

[BitHighlander]

Addressed in #620 at 41ec6eea.

A shared transaction_multisig_quorum_is_valid() predicate now enforces has_m && 1 <= m <= n <= 15. Signing validates outputs before proceeding, and both multisig compiler functions independently fail closed. Native regressions cover m > n, m = 0, values above 15, and a valid quorum; the full emulator matrix passes.

Leaving open until #620 CI and review complete, including review of the requested device-level no-signature-return coverage.