fix(core/prodtest): fix tropic version and chip id commands error handling
What the developer wrote
Authored by tychovrahe
fix(core/prodtest): fix tropic version and chip id commands error handling
[no changelog]
What changed, and why it matters
This commit fixes error handling in a Trezor factory-production test tool for the Tropic chip. Previously, when the chip failed to return a firmware version or chip ID, the tool would print an error but then continue and print a second 'OK' response with whatever leftover data happened to be in memory. The fix makes the function return immediately after the error, and also checks the correct success/failure code and clears the buffers first. It is a bug fix in an internal manufacturing diagnostic command, not a user-facing wallet security flaw.
No end-user action needed. For manufacturing/QA, ensure production-test firmware is updated so diagnostic commands report failures unambiguously and do not leak uninitialized stack contents.
Security signals we found
Missing return after error path leading to dual/conflicting CLI responses
Use of uninitialized stack buffer in response path
Incorrect success/failure check (boolean vs LT_OK return code)
Evidence from the diff
In core/embed/projects/prodtest/cmd/prodtest_tropic.c, three CLI commands (prodtest_tropic_get_riscv_fw_version, prodtest_tropic_get_spect_fw_version, prodtest_tropic_get_chip_id) now return after calling cli_error() on failure, initialize their local buffers to zero, and compare the lt_get_info_* return value against LT_OK instead of using a boolean negation. The prior code could emit both an error response and a subsequent OK response containing uninitialized or stale stack data, which is a logic/correctness issue in a production-test utility.
Changed components
core/embed/projects/prodtest/cmd/prodtest_tropic.cTrezor production-test CLI for Tropic secure elementInspect captured patch +7 / −4
diff --git a/core/embed/projects/prodtest/cmd/prodtest_tropic.c b/core/embed/projects/prodtest/cmd/prodtest_tropic.c
index a8f7b3716..49b50682a 100644
--- a/core/embed/projects/prodtest/cmd/prodtest_tropic.c
+++ b/core/embed/projects/prodtest/cmd/prodtest_tropic.c
@@ -56,6 +56,7 @@ static void prodtest_tropic_get_riscv_fw_version(cli_t* cli) {
uint8_t version[LT_L2_GET_INFO_RISCV_FW_SIZE] = {0};
if (lt_get_info_riscv_fw_ver(handle, version, sizeof(version)) != LT_OK) {
cli_error(cli, CLI_ERROR, "Unable to get RISCV FW version");
+ return;
}
// Respond with an OK message and version
@@ -70,9 +71,10 @@ static void prodtest_tropic_get_spect_fw_version(cli_t* cli) {
lt_handle_t* handle = tropic_get_handle();
- uint8_t version[LT_L2_GET_INFO_SPECT_FW_SIZE];
- if (!lt_get_info_spect_fw_ver(handle, version, sizeof(version))) {
+ uint8_t version[LT_L2_GET_INFO_SPECT_FW_SIZE] = {0};
+ if (lt_get_info_spect_fw_ver(handle, version, sizeof(version)) != LT_OK) {
cli_error(cli, CLI_ERROR, "Unable to get SPECT FW version");
+ return;
}
// Respond with an OK message and version
@@ -87,9 +89,10 @@ static void prodtest_tropic_get_chip_id(cli_t* cli) {
lt_handle_t* handle = tropic_get_handle();
- uint8_t chip_id[LT_L2_GET_INFO_CHIP_ID_SIZE];
- if (!lt_get_info_chip_id(handle, chip_id, sizeof(chip_id))) {
+ uint8_t chip_id[LT_L2_GET_INFO_CHIP_ID_SIZE] = {0};
+ if (lt_get_info_chip_id(handle, chip_id, sizeof(chip_id)) != LT_OK) {
cli_error(cli, CLI_ERROR, "Unable to get CHIP ID");
+ return;
}
// Respond with an OK message and chip ID
Why this scored 23/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.