Firmware monorepo for Trezor One, Model T, and Safe devices.
Every captured commit receives deterministic security triage and a separate communication-quality score. Security candidates and broader second-pass signals receive full-patch Ollama analysis.
Aug 5 → Feb 61298 seen115 candidatesCompleteFeb 6 → Jun 6775 seen58 candidatesCompleteJun 6 → Jul 6217 seen13 candidatesCompleteJul 6 → Aug 5360 seen54 candidatesCompleteMessage quality measures whether a commit identifies its scope, purpose, rationale, testing, and supporting references. It does not change the security-severity score.
Public Git author strings; identities are not independently verified.
Last scanned 29 minutes ago
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 filesThis 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…
4a9cf168by cepetr+335−3112 filesThis 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…
429a283dby M1nd3r+45−74 filesThis commit changes one line in a build configuration file for the Trezor hardware wallet firmware. It adds the 'ward' feature to the existing 'miniscript' feature set. There is no direct evidence in the commit that this is a security fix;…
d434a636by Jakub Janků+1−11 fileThis commit adds a new disabled-by-default feature flag called 'ward' to the Trezor firmware build system. It does not change any production firmware behavior; it only wires up a placeholder MicroPython module and build options so that fut…
7b58e75aby Jakub Janků+55−018 filesThis commit turns on a compiler warning (-Wsign-compare) that catches places where signed and unsigned numbers are compared, and fixes the resulting warnings across the Trezor firmware. Most changes are clean-up casts and loop-index type c…
1cc940a4by cepetr+162−15247 filesThis commit is a simple user-interface cleanup. It removes one duplicate translation label ('Access hidden wallet') and makes the device use a single, consistent label ('Access wallet') when asking the user to confirm opening a passphrase-…
65402aecby Michal Kazda+2−103 filesThis commit is a simple user-interface cleanup. It merges two translation labels that both meant 'Passphrase wallet' into a single label, and updates the screens that used the old duplicate label. There is no security-relevant behavior cha…
7ce6887fby Michal Kazda+5−184 filesThis commit fixes a bug in the Trezor bootloader's firmware-update code. When updating firmware, the first block of data is fetched in two pieces: a small initial 'header prefetch,' then the rest. If a communication error happened and the …
dc937ba2by tychovrahe+81−711 fileThis commit is a code cleanup in the Trezor bootloader. It moves the generic, image-type-agnostic parts of firmware upload (chunk receiving, retry logic, flash erasing/writing, timeouts) into a new reusable module called wf_image_upload.c,…
caab7d9eby tychovrahe+772−4834 filesThis commit removes an unused Rust Cargo feature flag called 'ui' from the Trezor firmware build configuration. It is a cleanup change: the feature was always enabled in practice, so the code now compiles unconditionally. There is no secur…
1436fbc6by cepetr+2−158 filesThis commit changes how users confirm an Ethereum authorization screen on Trezor's 'Caesar' layout. Previously, the user had to hold down a button to approve; now a simple tap is enough. The change only affects the user-interface interacti…
e231cc94by obrusvit+50−502 filesThis commit is a routine internal cleanup that merges two separate build packages (one for real hardware firmware and one for the desktop emulator) into a single package. It moves source files into subdirectories and updates build scripts …
6be32440by cepetr+48−32025 filesThis commit is a minor build/test maintenance change. It adds a feature flag (USE_AES_GCM) so that AES-GCM tests are only run when the feature is actually enabled in a particular firmware build. There is no security fix or vulnerability be…
890aca93by cepetr+13−14 filesThis commit only adds or updates copyright and GNU license header comments in Python test and tooling files. It makes no changes to executable code, so it cannot introduce a security vulnerability or fix one.
6dc781c2by M1nd3r+1202−203250 filesThis commit is a straightforward code cleanup: it moves the on-screen title for multisig XPUB screens from hard-coded English text into the device's translation system. The visible text remains essentially the same, and there is no securit…
6d69df16by Michal Kazda+20279−2023911 filesThis is a cosmetic code cleanup. It moves punctuation and capitalization out of the Python code and into the translation files so translated strings are shown exactly as written. There is no security-relevant change.
162ed3a2by Michal Kazda+12−125 filesThis commit simply removes two unused Rust import statements (called `use` statements). It does not change any actual code behavior, logic, or security properties of the Trezor firmware.
a56f8c3dby Roman Zeyde+0−22 filesThis commit fixes a UI formatting bug in the Tron cryptocurrency flow on Trezor hardware wallets. A missing colon was added to account information labels shown on the device screen. The change is cosmetic and does not appear to affect cryp…
739c2968by Michal Kazda+19332−193364 filesThis commit is a straightforward user-interface refactoring. It bundles an account/path label together with its corresponding value into a single tuple, instead of passing them as four separate arguments. There is no security-relevant chan…
c66f6f4dby Michal Kazda+51−7413 filesExpand any commit for its author, full message, clarity score, changed files, triage signals, analysis, and source link.
bbbfa2af · Sep 1, 2026 · 3 filesInformational 15refactor(core): separate norcow config from flash layout
`norcow_config.h` lived in the flash module and was pulled in by
`sys/flash.h`, while storage's `norcow.h` includes `norcow_config.h`,
which itself includes `sys/flash.h` — a cycle between the two modules.
Split it along its natural seam:
- `STORAGE_AREAS` / `STORAGE_AREAS_COUNT` are flash layout (defined by
`flash_layout.c`, used by `flash_utils.c` and the bootloader emulator),
so they join the other area declarations in `sys/flash.h`.
- The norcow parameters move to `sec/storage/inc/norcow_config.h`, next
to the module that needs them, and `NORCOW_SECTOR_COUNT` is now derived
from `STORAGE_AREAS_COUNT` so the two cannot disagree.
`projects/unix/main_main.c` uses `MODEL_INTERNAL_NAME` but reached
`trezor_model.h` only through the removed include chain, so it now
includes it directly.
Legacy and `storage/tests` are unaffected: each supplies its own
`norcow_config.h`.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
[no changelog]
This commit is a straightforward internal code cleanup. It moves two configuration constants between header files to remove a circular include dependency between the flash and storage modules. There is no user-facing change, no bug fix, and no security-sensitive behavior change.
f52c3833 · Sep 1, 2026 · 6 filesTriage 0chore(core): update qr-code-generator crate
[no changelog]
c81e063e · Sep 1, 2026 · 3 filesLow 42fix(core/rust): adjust menu item limits to prevent overflow errors
[no changelog]
This commit fixes a capacity mismatch in the Trezor hardware wallet's on-screen menus. A global limit allowed up to 6 menu entries, but the internal storage for two menu layouts only held 5. When a 6-item menu was built, the code would panic (crash) instead of showing the menu. The patch raises both storage capacities to 6 and adds compile-time checks so the bug cannot silently recur if the global limit is changed again. The crash is a denial-of-service issue for the device UI, not a direct theft-of-funds vulnerability.
e4a7d054 · Sep 1, 2026 · 2 filesInformational 15feat(core): report `Ethereum_EIP7702` from `GetFeatures`
1st part of https://github.com/trezor/trezor-firmware/issues/7693.
[no changelog]
This commit simply advertises that Trezor Model T / Core devices support a new Ethereum feature called EIP-7702 when a host asks the device for its capabilities. It does not change how transactions are signed, authorized, or validated. There is no security-relevant behavior change.
f43d6796 · Sep 1, 2026 · 5 filesTriage 0feat(common): add `Capability_Ethereum_EIP7702` to protobuf definitions
[no changelog]
fa008a3b · Aug 31, 2026 · 1 fileTriage 0fix(core): avoid underflow in offset validation
[no changelog]
79d2aa73 · Aug 31, 2026 · 1 fileLow 37fix(core): avoid panic on sentinel glyph lookup
[no changelog]
This commit fixes a bug in the Trezor firmware's translation system where looking up a special 'sentinel' (end-marker) value could cause the device to crash (panic). The fix changes the code to safely check whether the next entry exists before reading it, returning 'not found' instead of crashing. A test was added to confirm the sentinel lookup no longer panics.
724737f5 · Aug 31, 2026 · 136 filesInformational 15chore: use ruff instead of black and isort
- reducing the number of tools in the repo
- in the future, we may replace also pylint and pyright
[no changelog]
This commit is a routine housekeeping change that swaps the Python code-formatting tools used in the project from `black` and `isort` to `ruff`. It updates configuration files, build scripts, and reformats many source files to match the new tool's style. There is no change to what the software actually does, no new features, and no indication of any security problem or fix.
2df593a0 · Aug 31, 2026 · 1 fileTriage 0feat(core/tests): adjust tests to match new menu implementation
[no changelog]
1601205f · Aug 31, 2026 · 12 filesInformational 17fix(core): cleanup menu handling irregularities
[no changelog]
This commit is a code cleanup in the Trezor firmware's user-interface layer. It moves a small 'menu item intent' type to a better location, fixes a minor error-handling inconsistency, and reorders some on-screen menu entries so the cancel option appears first. There is no direct evidence this fixes an exploitable security vulnerability, but the reordering could be a defensive usability improvement to prevent accidental destructive actions.
1dab0acb · Aug 31, 2026 · 4 filesTriage 0fix(l10n): shorten where needed (en only)
[no changelog]
6999d093 · Aug 31, 2026 · 1 fileLow 45fix(core): refuse an emulator BLE read that cannot take a whole packet
The socket is SOCK_DGRAM, so `recvfrom()` consumes the datagram whole and
discards whatever does not fit the buffer it is given. Passing
`MIN(max_len, sizeof(buf))` therefore let a caller with a short buffer destroy
part of a received packet and get only its own length back - the emulator's
version of the defect just fixed in the hardware driver, reached through UDP
truncation rather than a queue dequeue.
Reject a `max_len` below the packet size before reading, as the hardware
driver now does, and read a whole buffer unconditionally: with the check above
it, the MIN could only ever pick `sizeof(buf)`.
No caller is affected. `py_iface_read()` requires a buffer at least
`RX_PACKET_SIZE` long and the bootloader wire layer requires an exact size;
only a direct `ble_read` syscall could ask for less.
[no changelog]
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This commit fixes a bug in the Trezor emulator's Bluetooth-over-UDP code. Previously, if a caller asked to read a Bluetooth packet into a buffer smaller than a full packet, the emulator would silently throw away the leftover data. Now it refuses short reads up front, matching a fix already made in the real hardware driver. The commit message says no real callers were affected because all normal callers use full-size buffers.
43cc18ab · Aug 31, 2026 · 1 fileTriage 0fix(core): cap the emulator's BLE read at one packet
`ble_read()` sized a stack array from `max_len`, a caller-supplied uint16_t:
uint8_t buf[max_len] = {};
That is a variable-length array, so the caller decided how far the stack
pointer moved, and the empty initialiser turned into a runtime memset over the
same length. Nothing bounded it but the width of the type - 64 KB.
It only ever saw 244 bytes, because `py_iface_read()` passed the constant
`RX_PACKET_SIZE`. That is no longer true: the length now comes from the
buffer, so a Python caller handing over a large bytearray sizes the array
with it. The hardware driver never returns more than one packet, so cap the
read there and use a fixed buffer. Reads at or below the packet size behave
exactly as before.
While here, return 0 rather than `false` from a uint32_t function on the
disconnected path.
[no changelog]
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
f9c35369 · Aug 31, 2026 · 1 fileLow 45fix(core): stop ble_read() consuming a packet it cannot return
`ble_read()` dequeued from the RX queue and only then checked that the caller's
buffer was big enough. `tsqueue_dequeue()` resets the entry and advances the
read index unconditionally, and there is no re-enqueue on the error path, so a
buffer below `BLE_RX_PACKET_SIZE` silently destroyed a received packet and
reported zero bytes - indistinguishable to the caller from an empty queue.
The size test never needed the dequeued data. Once `read_len` is known to be
`BLE_DATA_SIZE`, `max_len < read_len - BLE_DATA_HEADER_SIZE` is just
`max_len < BLE_RX_PACKET_SIZE`, so hoist it above the dequeue. That also
retires an expression that was only in bounds thanks to the `||`
short-circuit ordering.
`py_iface_read()` rejects a short buffer before it gets here and the bootloader
wire layer requires an exact size, so the only way in is an applet calling the
`ble_read` syscall directly - which loses packets addressed to itself. No
caller changes behaviour: for every `max_len` at or above the packet size the
function does exactly what it did.
[no changelog]
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This commit fixes a bug in the Bluetooth code of Trezor hardware wallets. When a program asked to read a Bluetooth packet using a buffer that was too small, the code would first remove the packet from the receive queue and only then realize the buffer was too small. Because the removed packet was not put back, it was silently lost. The fix checks the buffer size before removing the packet, so an undersized read now simply reports 'nothing available' instead of destroying data. The commit notes that the only realistic way to trigger this is an applet making a direct system call with a too-small buffer, which would cause that applet to lose packets meant for it.
8b6adf43 · Aug 31, 2026 · 2 filesModerate 58fix(core): tie ble::read()'s length to its buffer
`read()` took the buffer and the length the caller claims for it as separate
arguments, and passed the length straight to `ble_read()`. `ble_read()` writes
a full `BLE_RX_PACKET_SIZE` packet whenever the length it is given is at least
that big, so a caller passing a length larger than its buffer gets 244 bytes
written into something shorter.
The one caller, `py_iface_read()`, hands `read()` a Python-supplied buffer of
arbitrary size and passed the constant `RX_PACKET_SIZE`. It checks
`buf.len() < RX_PACKET_SIZE` first, so nothing is wrong today - but that check
is the only thing standing between a short bytearray and an overflow.
Derive the length from the buffer so the two cannot disagree. `ble_read()`
then refuses to write at all when the buffer is too small, and the check in
`py_iface_read()` is left to produce a clearer error rather than to keep us in
bounds. Saturate rather than fail the conversion: the length is only compared
against the packet size, so a buffer above 65535 bytes must keep working.
[no changelog]
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This commit fixes a potential buffer overflow in the Bluetooth Low Energy (BLE) read function of the Trezor hardware wallet firmware. Previously, the function trusted the caller's claim about how large the buffer was, which could allow more data to be written into a smaller memory area than intended. The fix makes the function use the actual buffer size instead, removing that trust relationship and preventing a possible overflow.
7bd1eaea · Aug 31, 2026 · 2 filesTriage 0refactor(core): drop the unused nRF DFU comm helpers
`nrf_dfu_comm_send()` and `nrf_dfu_comm_receive()` have no callers in C,
headers or Rust - the SMP transport talks to the UART through
`nrf_uart_send()` and `smp_process_rx_byte()` instead.
`nrf_dfu_comm_receive()` also under-reported by a byte on the partial-read
path (`len - RxXferCount - 1`), so this is one less thing to get wrong later
in a driver that parses untrusted input.
[no changelog]
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
a5ab04a5 · Aug 31, 2026 · 1 fileTriage 0fix(core): stop nrf_authenticate() aliasing its own info buffer
The liveness check passed `&drv->info` to `nrf_get_info()`, which copies into
its argument from `drv->info` - a memcpy with identical source and
destination, which is undefined behaviour. The result was never read; the call
is only there to confirm the nRF is talking to us before the challenge goes
out. Use a local.
[no changelog]
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
0ca9f38b · Aug 31, 2026 · 1 fileTriage 0fix(core): guard the nRF driver state shared with the SPI callback
`nrf_get_info()`, `nrf_get_version()` and `nrf_authenticate()` poll a flag set
by `nrf_management_rx_cb()` and then read the buffer it fills, all outside any
lock. The callback runs in the SPI interrupt, so it can land between the flag
test and the copy: a second response arriving mid-`memcpy()` leaves the caller
with two responses spliced together. For `nrf_authenticate()` that means a
mixed MAC and a failed boot.
Take the copy under `irq_lock()`, the way `ble_get_mac()` and
`ble_get_bond_list()` already do, and the way `nrf_system_off()` does a few
lines further down in this same file. The HMAC comparison is deliberately left
outside the lock - there is no reason to run it with interrupts disabled.
[no changelog]
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
a3fd85a0 · Aug 31, 2026 · 2 filesModerate 62fix(core): validate length in the nRF service callbacks
`nrf_management_rx_cb()` and `nrf_test_cb()` select on `data[0]` without
checking that a byte is present, and the two management handlers went further
on the same assumption, computing `len - 1` and clamping the result with
MIN(). A zero-length frame turned that subtraction into 4294967295, so the
clamp always picked the full struct size.
The reads stayed inside the SPI frame buffer, so nothing was out of bounds.
The defect is that a truncated response was accepted as a complete one:
- a one-byte MGMT_RESP_INFO set `info_valid` while leaving `drv->info`
holding whatever a previous exchange left there,
- a one-byte MGMT_RESP_AUTH_RESPONSE set `auth_data_valid` with `auth_data`
still zeroed, which `nrf_authenticate()` then fed to the MAC comparison.
Both fail closed, but `nrf_authenticate()` gates boot in production builds and
has no business deciding anything from a frame the nRF never filled in.
Require the whole payload before marking the state valid, and set the flag
after the copy rather than before. The minimums match what the nRF sends:
`send_info()` transmits `1 + sizeof(nrf_info_t)` bytes and
`mgmt_process_challenge()` more than the digest we read. An older nRF that
sent less would now fail `nrf_get_info()` and fall through to the SMP path,
which forces an update - the outcome we want.
This is the same defect class as the recent fix to
`ble_process_rx_msg_mac()`; these were the remaining callbacks.
[no changelog]
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This commit fixes a bug in the Trezor hardware wallet's code that talks to the nRF wireless chip over SPI. The code read the first byte of a received message to decide what kind of response it was, without first checking whether any bytes had actually been received. For two important response types—device info and authentication data—it then marked the data as 'valid' before copying it. A zero-length or truncated message could therefore make the device believe it had received valid authentication data when it had not. The device 'fails closed' (it does not unlock anything from bad data), but the bug could still let an empty or truncated frame influence the boot-time authentication check, which is not a safe design. The fix requires the full expected payload length before marking anything valid and moves the 'valid' flag to after the copy.
6af91f1f · Aug 31, 2026 · 1 fileTriage 0chore: update signed secmon for T3W1
```
464fcb1d38dff33abc3622b1f1ff35585f6af200de2781fa59c8deda6fd2450c core/embed/models/T3W1/secmon/secmon.bin
```
[no changelog]
(cherry picked from commit 66ac7295aaa0aa9fb427a0cc035b34dd61b6d472)
bd8c3eed · Aug 31, 2026 · 1 fileLow 35fix(core/fido2): use a static counter when returning a bogus signature
[no changelog]
This commit changes how the Trezor hardware wallet handles FIDO2/WebAuthn 'silent authentication' attempts. When a website asks for authentication without user confirmation (user presence=false), Trezor now returns a fake signature and a fixed counter value of 0, instead of advancing the real signature counter. Previously, the code advanced the real counter even when returning a fake signature. The change prevents the real counter from leaking or being consumed during silent authentication attempts, which is a minor privacy and state-consistency improvement.
dcdb96bc · Aug 31, 2026 · 1 fileModerate 61fix(core): fix nrf tlv offset calculatiion wrap
[no changelog]
This commit fixes a bug in the Trezor hardware wallet's firmware update code for the nRF wireless chip. The code reads update image headers from an untrusted source and calculates where to look for a SHA-256 hash inside the image. Before the fix, the calculation used a signed offset type and did not check whether the claimed image size was larger than the actual buffer. A malicious or malformed update image could make the offset wrap around (become a small number due to integer overflow), bypassing later safety checks and potentially causing the device to read memory outside the intended buffer. The fix rejects images whose claimed size exceeds the buffer and uses an unsigned type for the offset calculation.
c5e2fa2f · Aug 31, 2026 · 1 fileTriage 0fix(core): cheeck ble mac message len before processing its data
[no changelog]
c1b9a5be · Aug 31, 2026 · 2 filesTriage 0fix(core): check data length in ble_write
[no changelog]
659d5ada · Aug 31, 2026 · 2 filesInformational 15feat(core/caesar): use Marquee in Homescreen label
[no changelog]
This commit is a user-interface polish change for the Trezor hardware wallet. It replaces a static text label on the device homescreen with a scrolling 'marquee' label so that longer text (such as a wallet name) can be read even if it does not fit in the available space. There is no security-relevant change here.