CommitWatch RSS
AI-generated analysisPublished automatically and not human-verified. Validated context appears in community notes below.
← Watch feed
Low 37 Bitcoin

fix(core): correct timestamp conversion in `time_gmtime2000()`

TZd0f50b4d View source ↗
Public commit record

What the developer wrote

Authored by Roman Zeyde

95/100 · Strong
fix(core): correct timestamp conversion in `time_gmtime2000()`

It was working on the emulator (since `mp_int_t` is 64-bit)
but failing on HW devices.

Also, improve `test_lock_time_datetime` coverage.

Note: `2106-02-07 06:28:15` = 2**32-1 seconds from epoch.
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Uses a recognizable type or scope✓ Provides detailed explanatory context✓ Mentions testing or verification
The short version

What changed, and why it matters

This commit fixes a date-handling bug in Trezor hardware wallets. The device converts Bitcoin transaction lock-time timestamps into human-readable dates on its screen. Before the fix, the code used a 32-bit signed integer on real hardware, so any date after the year 2038 (and in practice after about 2068 in this code) would be misread and the wrong date would be shown to the user. The fix switches to a 64-bit timestamp type and adds tests for far-future dates up to the year 2106. The main risk is that a user could be tricked into approving a transaction whose real lock-time date is different from what the device displays.

Recommended action

Treat as a low-severity correctness fix with possible user-interface security implications. Ensure the fix is included in the next firmware release. Review whether any other call sites still use mp_obj_get_int() for timestamp values. No immediate incident response is required; the bug requires a crafted future lock-time date and only affects on-screen display, not transaction validation semantics.

Security signals we found

01

Integer width mismatch between emulator (64-bit mp_int_t) and hardware (32-bit mp_int_t)

02

Timestamp truncation/overflow for dates beyond 32-bit signed range

03

User-facing date formatting used during transaction approval

04

Bitcoin lock-time (nLockTime) absolute timestamp parsing affected

05

Compile-time assertion added to prevent regression

06

Test coverage extended to year 2106 (2^32-1 seconds since 2000 epoch)

Risk score

Why this scored 37/100

Our methodology →
Potential impact 8/30
Exploitability 5/25
Stealth signal 6/15
Affected reach 7/15
Confidence 7/10
Evidence quality 4/5
Human-validated context

Community notes

Notes can correct, qualify, or add evidence to the AI analysis. Every note shown here has been validated by a human moderator.

No validated notes yet.

The AI analysis stands alone for now. Submit a note if you can add evidence or important context.

More from Trezor firmware

Related watches

Informational 15 AI analysisMessage 57 · Thin
TZ TrezorTrezor firmware BitcoinHardware wallets

chore(core): improvements to English copy

This commit is a routine text cleanup for the Trezor hardware wallet's on-screen English messages. It fixes punctuation, removes unnecessary line breaks, and makes small wording tweaks (for example, changing 'PIN will be required' to 'A PI…

1dbc2c3cby Michal Kazda+22−422 files
No security note in commit
Open full analysis →Source commit ↗
Moderate 59 AI analysisMessage 57 · Thin
TZ TrezorTrezor firmware BitcoinHardware wallets

feat(core): app root packet downgrade protection

This commit adds downgrade protection for a new 'app root packet' system in Trezor firmware. Previously, the code had a TODO note saying downgrade protection needed to be considered. The change makes the device remember the timestamps of p…

Replaces a TODO comment ('!@# TODO: Consider downgrade protection') with concrete timestamp-based anti-downgrade checksAdds per-ring timestamp state to prevent rollback of root-of-trust packetsAdds chain_timestamp field and 90-day drift bound to root packet format
4a9cf168by cepetr+335−3112 files
No security note in commit
Open full analysis →Source commit ↗
Moderate 67 AI analysisMessage 62 · Adequate
TZ TrezorTrezor firmware BitcoinHardware wallets

fix(core/rust): discard low-order keys in THP handshake

This commit fixes a cryptographic edge case in Trezor's THP (Trezor Host Protocol) handshake. It now rejects Curve25519 public keys that are all zeros or that produce an all-zero shared secret. A zero public key can cause the Diffie-Hellma…

Curve25519 zero/low-order public key rejection added to DHZero shared-secret output rejected after scalar multiplicationHandshake state machine now transitions to Failed on initiation-response error
429a283dby M1nd3r+45−74 files
No security note in commit
Open full analysis →Source commit ↗