KarpelesLab / libwallet / 24875986296

25%

push

github

wltacct: fix Account.IL JSON roundtrip through any (chain_switch crash)

User report: wallet_switchEthereumChain to Linea (0xe708) crashes
on libwallet 0.4.1, MetaMask test-dapp, with:

  chain_switch: malformed request value:
  math/big: cannot unmarshal "1.7436763532287587e+76" into a *big.Int

Root cause: Go's encoding/json silently IGNORES the `,string` struct
tag for fields whose type provides a custom MarshalJSON, including
`*big.Int`. So the `IL,string` tag on Account.IL has been a no-op
on the encode side since forever — IL gets emitted as a raw JSON
number (`"IL":29384...`).

That's harmless for direct Account ↔ Account JSON roundtrips (the
decoder is lenient: it converts JSON number to text and feeds
big.Int.UnmarshalText, which accepts decimal). But anywhere
Account passes through an `any` intermediate — psql loads JSON
columns into map[string]any with JSON numbers becoming float64 —
the 254-bit IL gets rounded to "1.74e+76" via float64. The next
re-marshal emits scientific notation, big.Int.UnmarshalText rejects
it, and the chain_switch approval handler bombs.

The chain_switch flow specifically: requestChainSwitchForTarget
attaches CandidateAccounts (with their *big.Int ILs) to a request
whose Value field is `any`. Save→psql→load→decodeChainSwitchValue
walks IL through the lossy float64 path. Any user trying to add
a chain that isn't already in their wallet hits this.

Fix: override Account.MarshalJSON to emit IL as a JSON STRING
explicitly, sidestepping the ,string-tag-ignored-for-big.Int
quirk. A Go string survives map[string]any verbatim, re-marshals
as the same JSON string, and the existing decode path parses it
back into *big.Int.

Account.UnmarshalJSON also added — accepts the new string form,
the legacy raw-number form (backward compat with already-stored
data), and (best-effort) scientific notation for already-corrupted
DB rows so users with a poisoned chain_switch request can still
get past the approval flow rather than being per... (continued)

0 of 36 new or added lines in 1 file covered. (0.0%)

2748 of 14078 relevant lines covered (19.52%)

58.34 hits per line