Trezor firmware

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 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 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 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 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 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 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 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.

This commit fixes an out-of-bounds memory read bug in the Trezor bootloader's firmware header parser. The read_vendor_header function previously trusted size values inside a firmware file without first checking whether those sizes fit within the actual data buffer. A malformed firmware update or a corrupted on-device firmware image could have caused the bootloader to read memory beyond the allowed region. The patch adds size checks so the parser rejects too-small or oversized headers before using their contents.

This commit renames and restructures how Trezor firmware selects cryptographic signing keys for bootloaders. Previously, non-production builds automatically used weaker development/QA keys. Now, a dedicated BOOTLOADER_DEVEL flag controls that, while a separate FORCE_BOOTLOADER_UPGRADE flag controls whether the firmware should forcibly update the bootloader. The change also prevents combining PRODUCTION=1 with BOOTLOADER_DEVEL=1. This is primarily a build-hardening and internal workflow cleanup; it does not by itself fix a remotely exploitable bug in shipped devices.

This commit fixes a bug in the Trezor hardware wallet's NFC driver where calling the NFC shutdown function more than once could crash the device. The fix adds a simple check to skip re-deinitializing the SPI hardware if it has already been shut down. It is a defensive hardening fix rather than a clear exploitable vulnerability.

This is a minor code cleanup that changes when a debug-only warning message is printed. It does not fix or introduce any security issue. The change simply avoids logging a misleading warning when no backup method is selected in a non-production debug build.

This commit only updates the expected visual-output fingerprints (called 'fixtures') used by the device's automated UI tests. It renames test cases to include a '[Display]' marker and adjusts the corresponding hashes, but does not change any firmware code that runs on the Trezor device itself. There is no security-relevant change visible in this commit.

This commit adds a new backup and recovery method called N4W1 to Trezor firmware. It is a feature addition that lets users back up and restore their wallet seed using a near-field wireless tag instead of typing words on the device screen. The change is mostly about adding new code paths and tests; it does not appear to fix a known security bug, nor does the vendor describe it as a security patch.

This is a routine lock-file update for a Python dependency manager. It records that an internal Trezor package named 'tvl' now depends on two additional libraries ('cffi' and 'libcst'). There is no indication of a security fix, vulnerability, or malicious change in the commit itself.

This commit is a simple code cleanup in the Ethereum clear-signing module. It pulls out a repeated snippet of code that reads variable-length data into a new helper function, then replaces two copies of that snippet with calls to the helper. No behavior changes are visible in the diff.

This commit adds a length check to a function that parses arrays of 256-bit unsigned integers in Ethereum transaction data. Previously, if the raw data was not a multiple of 32 bytes, the function would silently ignore leftover bytes at the end. The fix now raises an error instead. This could matter for 'clear signing' displays on a Trezor hardware wallet, where malformed data might otherwise be shown or processed in a misleading way. The commit message does not describe this as a security fix, and no exploit is demonstrated.

This commit replaces runtime computation of two Ethereum function signatures with hard-coded byte values, then adds debug-only assertions to verify those values still match the original computation. It is a minor code cleanup with no apparent security impact. The change does not alter what the device signs, displays, or accepts.

This commit adds a safety check to a function that verifies unused data is zeroed. Before the change, if a caller passed an invalid 'used_bytes' value (for example, a negative number or one larger than 32), the function could read memory outside the intended 32-byte window or behave unexpectedly. The patch now rejects such invalid values immediately. The commit message calls it a routine cleanup ('chore') and does not claim it fixes a security vulnerability.