fix(solana): fall back to generic UI if stake lockup set
What the developer wrote
Authored by Jakub Janků
fix(solana): fall back to generic UI if stake lockup set
Prior to this change, the predefined staking flow allowed
lockup.custodian = _SYSTEM_PROGRAM_ID, lockup.epoch > 0, and
lockup.unix_timestamp > 0. However, these values were not displayed
to the user. This could lead to the user loosing access to their
funds if the time values were set to distant future.
The change should not modify the behavior when working with Suite since
it generates init instructions with lockup.epoch=0 and
lockup.unix_timestamp=0:
https://github.com/trezor/trezor-suite/blob/7de6f3e/networks/solana/network-solana/src/runtime/stakingUtils.ts#L104-L118
Partially fixes: https://github.com/satoshilabs/trezor-firmware/issues/325
(cherry picked from commit 5a12ad231741e0406f9d7f7a0b2e15a7237f0bbd)
What changed, and why it matters
This update fixes a security gap in Trezor's handling of Solana staking. Previously, if someone set up a stake account with a future unlock date (a 'lockup') using values that Trezor's normal flow didn't expect, the device would silently approve the transaction without showing those lockup details on screen. That could trap a user's funds until a far-future date. The fix makes Trezor fall back to a more detailed, generic confirmation screen whenever a lockup is present, so the user can see and approve the terms explicitly.
Treat this as a security fix and include it in the next firmware release. Users who sign Solana staking transactions through non-Suite dApps should update. Review other predefined transaction flows for similar fields that are accepted but not displayed.
Security signals we found
Hidden lockup parameters in a predefined signing flow
User-visible confirmation bypass for time-locked funds
Fallback to generic UI for unreviewed instruction fields
Funds-availability risk due to undisclosed future unlock conditions
Evidence from the diff
The Solana predefined staking flow in Trezor firmware accepted Stake Initialize instructions where lockup.custodian was the system program but lockup.epoch or lockup.unix_timestamp were non-zero. Those lockup fields were not rendered in the predefined UI, so a malicious or buggy dApp could set a distant-future lockup and the user would not be prompted to review it. The patch adds a guard so that any non-zero lockup timestamp or epoch causes the flow to fall back to the generic transaction UI, where all instruction data is shown for confirmation. The vendor notes this does not affect Trezor Suite, which already initializes stakes with zero lockup values.
Changed components
core/src/apps/solana/predefined_transaction.pySolana staking predefined transaction flowTrezor device display/confirmation UIInspect captured patch +3 / −0
### core/.changelog.d/+solana_stake_lockup.security
@@ -0,0 +1 @@
+Solana: Ask user for confirmation of stake lockup settings, which were previously hidden.
### core/src/apps/solana/predefined_transaction.py
@@ -318,6 +318,8 @@ def _match_instructions(*expected_types: type[Instruction]) -> bool:
if base58.encode(init.custodian) != _SYSTEM_PROGRAM_ID:
return False
+ if init.unix_timestamp != 0 or init.epoch != 0:
+ return False
stake_account = create.created_account[0]
if stake_account != init.uninitialized_stake_account[0]:Why this scored 60/100
Community notes
Notes can correct, qualify, or add evidence to the AI analysis. Every note shown here has been validated by a human moderator.
The AI analysis stands alone for now. Submit a note if you can add evidence or important context.