Trezor firmware

This commit is a cleanup of how the word 'const' is used in the Trezor firmware's ed25519 cryptographic code. Previously, the code defined a custom 'CONST' macro that meant 'const' on newer compilers and nothing on older GCC versions. The commit removes that macro and uses plain 'const' everywhere. It also adjusts a Rust build script comment and compiler flag. There is no indication in the commit that this fixes a security vulnerability or changes runtime behavior.

This commit is a straightforward internal code refactor. It renames a build feature flag from 'applet' to 'applets' and replaces the KERNEL preprocessor guard with a new USE_APPLETS guard in the relevant source files. There is no change to actual security logic, no bug fix, and no indication of a vulnerability being addressed.

This commit changes a build configuration for Trezor's Unix emulator so that MicroPython uses the standard C setjmp/longjmp mechanism for non-local returns instead of a custom x86_64 assembly implementation. There is no direct security fix here; it is a portability/refactoring change. It does not affect the actual Trezor hardware firmware.

This commit updates the Trezor firmware build environment to include prebuilt Rust standard library support for a newer ARM processor target (thumbv8m, used in the T3 device model). It is a build tooling change with no visible security relevance.

This commit fixes how the Trezor firmware build generates a Rust binding for an internal identifier type called Qstr. Previously, the build always assumed the underlying C enum was a 32-bit integer, but the firmware actually compiles with smaller 16-bit enums. The mismatch could cause the generated Rust code to use the wrong size, leading to memory corruption or crashes when Rust and C exchange Qstr values. The patch makes the build choose the correct enum size for firmware versus host builds.

This commit is a code cleanup in Trezor's Ethereum transaction handling. It replaces a hand-rolled method of reading Ethereum vault transaction data with a shared, more structured parsing system called DisplayFormat. There is no indication this fixes a security bug; it appears to be a refactoring change with no functional security relevance stated by the vendor.

This commit updates the Trezor firmware build system and emulator code to use SDL3 instead of the older SDL2 library. It is a routine dependency migration affecting only emulator builds (software simulations of the hardware wallet), not the real device firmware. The changes rename functions and constants to match SDL3's API, adjust build scripts, and add a couple of small safety checks. There is no indication this fixes a known security vulnerability.

This commit only updates expected test result hashes (called 'fixtures') in a single test data file. The firmware code itself is not changed, and there is no indication of a security fix or vulnerability. It appears to be routine maintenance after switching the UI test framework to SDL3, which likely changed how screen snapshots are rendered and therefore changed their hashes.

This is a trivial board definition update for a Nordic chip configuration file. It adds a duplicate 'full_name' field that matches the existing 'name' field. There is no security relevance.

This is a routine cleanup change in the Nordic Bluetooth Low Energy firmware for Trezor hardware wallets. It replaces old-style printk debug messages with Zephyr's standard logging macros (LOG_ERR, LOG_WRN) and removes an unused logging configuration option. There is no security-relevant change here.

This commit tidies up build configuration files for Trezor's Nordic Bluetooth/radio test firmware. It removes some redundant or outdated settings, adds a couple of clarifying options, and disables over-the-air firmware update slots for test builds. There is no direct evidence in the commit that this fixes a security vulnerability; it reads as a routine cleanup of build settings.

This commit removes a single deprecated configuration option, CONFIG_NFCT_PINS_AS_GPIOS, from the Nordic Bluetooth Low Energy firmware build file. The change is a routine cleanup with no visible security relevance. It does not alter runtime behavior in a way that introduces or fixes a vulnerability based on the information provided.

This is a minor internal cleanup in the Nordic (nRF52) Bluetooth Low Energy firmware for a Trezor hardware wallet. It replaces a hard-coded reference to 'spi0' with a device-tree alias called 'spi-master' so the same code can more easily be reused across different board revisions. There is no security-relevant change visible in the diff.

This commit refactors a build script for Nordic hardware so that several hard-coded numbers (memory addresses, slot size, device model tag) are instead read from the project's generated device tree and configuration files. There is no change to runtime code, no new user-facing behavior, and no indication of a security fix or vulnerability.

This is a build-system refactor for Trezor's Nordic Bluetooth chip firmware. It removes manually maintained flash partition files and switches to Zephyr's standard device-tree partition definitions. The change also fixes a build-time signing script bug where a duplicate image header could be inserted, which would cause the device to crash immediately on boot. There is no direct evidence this is a security vulnerability patch, but it prevents a real boot failure in the manufacturing/development workflow.

This commit is a routine cleanup of the Nordic board configuration and Bluetooth Low Energy firmware for a Trezor hardware wallet. It removes the generic Nordic 'DK buttons and LEDs' driver and replaces it with direct GPIO (general-purpose input/output) definitions tied to the actual Trezor board pins. It also fixes a typo in the board name and renames some device-tree labels for clarity. There is no security-relevant change visible in the diff.

This commit fixes a logic error in the build scripts that decide whether to use development or production signing keys when preparing Trezor firmware images. Before the fix, the condition was accidentally inverted, so production builds may have used development keys and development builds may have used production keys. Using the wrong keys could make firmware signatures invalid or cause devices to reject genuine firmware, but the commit itself does not show an exploitable runtime vulnerability in shipped code.

This commit updates four GitHub Actions workflow files to use a newer version of an official GitHub action that creates authentication tokens for automated bots. It also renames a configuration setting from 'app-id' to 'client-id' to match the new action version's requirements. There is no change to the Trezor firmware code that runs on user devices, and no security vulnerability is present in the diff.

This commit is a code cleanup in the Trezor firmware's secure USB/Bluetooth transport layer (Trezor THP). It replaces a single shared buffer used during the cryptographic handshake with two separate buffers: one for messages being sent and one for messages being received. The change makes the code easier to reason about and removes some awkward buffer resizing and zeroing patterns, but it does not appear to fix any active security bug. There is no mention of a vulnerability, CVE, or security issue in the commit itself.

This commit refactors the internal state machine of Trezor's THP (Trezor Host Protocol) Rust code so that sending and receiving are tracked independently, enabling full-duplex communication in the future. It does not appear to fix a known security bug; it is a structural code change. There is no vendor statement or external report linking it to a vulnerability.

This commit is a code cleanup: it moves several fixed-size buffer length constants out of individual Rust source files and into a shared module so they can be reused consistently. The actual buffer sizes used during the cryptographic handshake are recalculated and, in some cases, slightly changed (for example, the device-properties limit drops from 128 to 64 bytes and a new allocation-response size is introduced). There is no direct evidence in the commit that this fixes a security vulnerability; it reads as a refactoring to make the code easier to maintain.

This commit adds a new optional transport-layer feature called 'ACK piggybacking' to the Trezor hardware wallet's Rust THP (Trezor Host Protocol) implementation. It lets a device or host include an acknowledgment (ACK) inside the next data packet instead of sending a separate tiny ACK packet, reducing USB/network traffic. The change is feature-gated by protocol version 2.1 and falls back to the older separate-ACK behavior if either side does not advertise support. The diff also includes related test and example-code cleanups, such as stricter error handling and a new API to set the peer's protocol version before the handshake begins.

This commit adds a missing safety check in the Trezor hardware wallet's core firmware. Two functions that validate boot images now verify that the firmware actually has permission to read the image's memory before processing it. Without this check, a malformed or attacker-controlled image pointer could potentially be passed in, leading to unauthorized memory reads or a crash during the boot verification process. The fix is straightforward and defensive.

This commit fixes several out-of-bounds (OOB) memory reads in the NFC card emulation code used in Trezor hardware wallets. The code previously trusted the length and content of NFC commands received from a nearby reader without checking whether the received data was actually long enough. A malicious or malformed NFC reader could send a truncated or specially crafted command, causing the device to read memory past the end of the command buffer. The patch adds length checks before accessing command bytes and before looping over variable-length block lists.

This patch fixes several integer-handling bugs in the Trezor bootloader's USB message decoder. The changes prevent small or maliciously crafted message sizes from causing arithmetic overflows or underflows when the device calculates how many USB packets to read. Such flaws could potentially let an attacker confuse the bootloader into reading memory out of bounds or behaving unpredictably during a firmware update.