transformERC20 is exempt from the data_total binding and signs an undisclosed calldata tail

[BitHighlander]

What is wrong

#413 added a central binding so a contract decoder cannot claim a transaction whose calldata exceeds the initial chunk:

// lib/firmware/ethereum_contracts.c
67:  if (data_total != msg->data_initial_chunk.size) return false;

transformERC20 is hoisted above it and exempt:

60:  if (zx_isZxTransformERC20(msg)) return true;

and the decoder still discards the total:

// lib/firmware/ethereum_contracts/zxtransERC20.c:57-58
bool zx_confirmZxTransERC20(uint32_t data_total, const EthereumSignTx* msg) {
  (void)data_total;

When any decoder claims a transaction, lib/firmware/ethereum.c:720-728 clears both needs_confirm and data_needs_confirm, and ethereum.c:693 admits data_length up to 16,000,000 streamed into the hash. So the tail is signed and never shown.

Why the exemption does not hold

The in-code justification is that the outcome is "bounded by the input amount and minimum output amount shown on screen". That is an off-device invariant — it is the 0x ExchangeProxy's own min-output check, not anything this firmware verifies.

It also rests entirely on msg->to matching ZXSWAP_ADDRESS on an allowlisted chain (ethereum_contracts.c:38-45), and #441 records that allowlist as unverified against 0x's published deployments. So the firmware is trusting a contract's behaviour, at an address it has not confirmed is that contract, on chains it has not confirmed the contract exists on.

Reachable today

A host that sets to = 0xdef1c0ded9bec7f1a1670819833240f027b25eff, chain_id in {1, 56, 137, 8453, 42161, 43114}, selector 0x415565b0, and data_length well beyond data_initial_chunk.size gets #413's exact stated harm: a recognised, benign-looking call carrying arbitrary appended calldata that is hashed and signed after the user has approved.

Why this is filed separately

#413's commit (d674adf30) carries a Closes #413 trailer and states the residual in its own body. Without this issue, merging would auto-close #413 and this defect would leave the tracker entirely.

#400 does not cover it. That issue is about the generic layoutEthereumData path in ethereum.c — the screen a user reaches when no decoder claims the transaction. This is a decoder that does claim it and shows no raw data at all.

Options

1. Remove the exemption. transformERC20 falls to the generic disclosure when it does not fit one chunk — consistent with every other decoder, at the cost of a raw-hex screen for large 0x swaps.
2. Keep clear-signing but bind the tail: hash the streamed remainder and display a commitment the user can compare, or assert the decoded transformations[] covers exactly data_total bytes.
3. Keep the exemption deliberately, but only once Verify the 0x Exchange Proxy chain allowlist against 0x's published deployment data #441 is closed — the argument depends on the address and chain being what the firmware assumes.

Option 1 is the smallest and fails closed. Option 3 is not viable on its own while #441 is open.

How to verify

git show release/7.14.2:lib/firmware/ethereum_contracts.c | sed -n '52,70p'
git show release/7.14.2:lib/firmware/ethereum_contracts/zxtransERC20.c | sed -n '55,60p'
git show release/7.14.2:lib/firmware/ethereum.c | sed -n '690,730p'

[BitHighlander]

Fixed on release/7.14.2 by #468, merged as 2d2637747.

Closing manually: the commit carries Fixes #444. but GitHub only honours closing keywords for commits that land on the default branch, and this merged to release/7.14.2.

What landed

ethereum_contractHandled() now applies data_total != msg->data_initial_chunk.size before any decoder, including zx_isZxTransformERC20. A transformERC20 whose calldata exceeds one 1024-byte chunk no longer clear-signs; it falls through to the generic raw-calldata path (AdvancedMode-gated, bytes on screen).

That is Option 1 from this issue's own text — "remove the exemption; transformERC20 falls to the generic disclosure when it does not fit one chunk" — described here as "the smallest and fails closed".

The regression test negative-controls: rebuilt against the pre-fix ethereum_contracts.c it fails with Actual: true / Expected: false.

Measured cost, recorded in the release notes

This is not an edge case. The recorded mainnet fixture in deps/python-keepkey/tests/test_msg_ethereum_erc20_0x_signtx.py (etherscan 0xcf94f79d…) is 1480 bytes, with its second transformation (PayTakerTransformer) starting at byte 1060 — past the boundary. Dropping that transformation would strand funds in the Exchange Proxy, so no host emits a shorter form. Production 0x swaps now require AdvancedMode and get the raw-hex screen.

What this issue does NOT cover, so it is not lost

• The in-buffer residual. The gate proves the calldata was received, not displayed. transformERC20's ABI head is 164 bytes and the decoder reads only inside it, so a payload fitting one chunk still clear-signs with up to 860 bytes of transformations[] never read. That primitive is untouched by fix(evm): bind transformERC20 clear-signing to full calldata #468 — the code it lives in is not modified by the diff — and it belongs to EVM clear-sign decoders read confirmation text from hardcoded ABI offsets without consulting the offset word #414, which names zxtransERC20.c and describes decoders reading confirmation text from hardcoded ABI offsets without consulting the offset word.
• The chains where no amount renders at all. TokenType.chain_id is uint8_t, so Base/Arbitrum/Avalanche truncate and both operands render "Unknown token value" — removing the very bound that justifies clear-signing transformERC20. Tracked as Token table chain_id is uint8_t, so Base/Arbitrum/Avalanche cannot be represented at all #455; near-term mitigation in fix(evm): drop Base, Arbitrum and Avalanche from the 0x decoder allowlist #470, which drops those three from the decoder allowlist.

[BitHighlander]

Correction to my comment above: I named the wrong owner for the residual.

I wrote that the in-buffer residual — up to 860 bytes of transformations[] the decoder never reads — belongs to #414. It does not. #414 is about the unread ABI offset word: a caller placing its real arguments elsewhere so the hardcoded positions display plausible-but-wrong values. That is misdirection, and it is fixed at head (canonical-offset pinning in zxswap.c:69-74 and thortx.c:70-74).

The residual here is non-disclosure, not misdirection: bytes that are never read or shown at all. Different failure mode, and it had no owning issue.

Now tracked as #473. Nothing about this issue's own closure changes — #444 was scoped to the streamed tail and #468 fixed exactly that.